Steps:
- In home, expense app icon: "Go to the expense
to attach a receipt"
- In list, on create button : "Click here to create
your first expense and add it to below."
- In form, on save button : "Once your Expense is
ready, you can save it."
- In form, point out the chatter "Attach your
receipt here."
- In list, point out record selection: "Select
expenses to submit them to your manager"
- Point out "Action": "Click on Action Submit To
Manager to submit selected expenses to your manager"
- In expense sheet point out approve “Approve the
sheet here. Tip: if you refuse, don’t forget to
give the reason thanks to the hereunder message
tool".
This behavior kind of disappear with 48ea59d46e
Moreover, since the Analytic Accounting is hidden, and
a AA on expense is required to reinvoice product on
SO, an AA should be on the SO as default value.
The main change is we use SO and not analytic account
anymore to reinvoice expense.
When encoding an expense, each employee can directly
set the SO to allow re-invoicing the expense to a
client. Before this commit, this was done by determining
the SO based on the Analytic Account (magically) on the
expense.
This solution is less confusing and more explicit for
the end user.
This commit also bring usability improvements to
improve user experience during this flow:
- better expense product view
- access group on menu items
- ...
Each move line generated from an expense posting will
be linked to the original expense. Some of those move
lines are for taxes, one for the product, ... but they
are all link to the same expense.
This will allow better reporting, and allow to access
the expense record from the move or its analytic lines
for futher developement.
The goal is to have a name_get for SO returning
a value like 'SO0002 - Michel F.'
To avoid performance problem, the chosen solution
is to add a context key 'sale_show_partner_name' to
provide the partner name in name_get(), otherwise
it will always add it and kill the performance.
This solution is preferred over adding a stored
related field for partner name (trigger recompute
when partner is renamed for all SO is bad).
Custory reading seems to denote that field names are probably already
text in the normal case, and thus should not need decoding? It only
blows up in a tour so...
* gitignore pycache folders (apparently appear for some)
* update xlwt requirement: 1.1.2 does not work with Python 3.6, 1.2 should work, 1.3 officially supports it
Split big universal RNG into view-specific schemas and moved rng based view validation
into view_validation.py file.
Adapt old views, and remove deprecated tag `version="7.0"` from views.
When running action_assign on a mts move bypassing the reservation,
we always created a new stock move line with the quantity of the move.
This proved to be too naive when running recheck availability.
Exemple: Let’s say I have a reserved move of quantity 5.
If I edit the initial demand to 7 and click on recheck availability,
I end up with a move line of 5 and a move line of 7. We adadapt the
code in a similar way that what’s done in _update_reserved_quantity,
by looking for a candidate move line and only increasing the reserved
quantity by what still needs to be reserved.
With the new views, we lost a (almost unused and undocumented) feature:
the ability to instantiate custom widgets in a form view, not linked to
a particular field. For example:
<widget type="weekly_timesheet" attrs="{'readonly': [['state', 'not in', ['new', 'draft']]]}"/>
We reintroduce this feature in this commit, with a nice twist: it also
works for the list view and the kanban view.
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
opw-749752
opw-751294
opw-751348
-Make a return picking from a SO, and condigure the items to be refunded on SO(in the wizard)
-Copy the return picking.
-Validate it.
Without this fix, it would just keep decreasing the delivered value on SO.
opw:767429
Add a `peek` option in the bus event dispatcher polling in order to let
an external event dispatcher fetch the notifications and their
corresponding channels.
Impacted modules: hr_timesheet, sale_timesheet, sale
and project_timesheet_holidays
The main change is the product configuration: a service
can create a task or a project, even if the update of
delivered quantities is manual.
Some code cleaning were done to ease comprehension and
maintenability.
This merge also bring usability changes and fine tuning
to manage your service like a pro.
For details, please have a look at sub commits.
Thanks for Thibault for the review and Benjamin (and Indian
Testing Team) for testing this. And Martin Trigaux that
did nothing, since he was on a stupid mountain ...
When a so line base on ordered quantities is invoiced, the timesheet
logged after the invoice validation are not marked as invoiced. This
shows wrong number on the Project overview.
Only project user can see stat button for project and
task on SO form view, and only timesheet user can
see the detailled timesheet stat button.
This avoid to give malny access rights to user that
does not required them for their daily business.
A leave type now generate timesheet by default. So
the internal project/task are taken from the leave
type company (a default value for the company has
been added).
To allow the hr leave manager to select a project,
he should be alble to read the analytic account
(otherwise, crash when calling name_get).
Setting the default internal project/task is advanced,
so hidden in debug mode on timesheet config.
Timesheet logged on project created from a SO line are
not exactly the same as the non billable ones.
To ease the reporting, we split the non billable type
of timesheet: when timesheeting directly on a project
(whatever the product config), the billable type will
be 'no task found'.
The Overview is adapt to display the 2 'non billable'
categories.
Dhawal Limbuwala