The 'help' of window action is often fiddled with, adding thing before,
after or arround it.
For example in CRM leads, we add at the beginning "Click to add a new
opportunity" with an arrow towards the button, and after if there is a
mail alias: "All email incoming to * will automatically create new...".
But for crm.lead, hr.expense, sale.order this would not take into
account that the fiddled "help" can be edited, so if we edit 2 times
help in studio or backend action editing, we would get:
Click to add a new opportunity
Click to add a new opportunity
Click to add a new opportunity
[Original help content]
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
All email incoming to * will automatically create new...
And see several "arrows" towards the button (in enterprise the
additional ones are on same color background).
With this commit we do what is done in "mail.thread" by default which is
not fiddling with the `help` if has been fiddled before (if it contains
"oe_view_nocontent_create" class).
note: this is the 11.0 version of #26912
opw-1877663
closes#26911
- Set a specific expense account on an expense product
- Send an email to the expense alias
The specific expense account is not used; a default account is used
instead.
opw-1838174
Before this commit:
Expense emails title are parsed to find a product that match the given [CODE].
For example, an email title like '[CARD] Graphic Card $900' will create an
expense for the product having 'CARD' as internal reference.
Since the search is done with an 'ilike' and with no 'limit', it could return
multiple product: all the one containing the CODE in their internal reference.
This would throw a singleton error when trying afterward to read product.id.
Then, the mail would not go through the mail.thread flow and it would return
a Mail System Delivery fail saying the address does not exist.
Users would get stuck with this, having no way to understand where the error
comes from.
Now, we ensure to find only 1 product.
To avoid breaking the ilike behavior that could be used by users only typing
the first caracters of a long CODE, we still use ilike but force exact match if
there is multiple results.
Closes#23419
opw-1816340
New rights were applied on hr.employee with this commit https://github.com/odoo/odoo/commit/2d777d5ade94f4a80862608e2807660f289d9923
Since, users with limited rights would see a read error when submitting an
expense to manager.
Indeed, when clicking on "SUBMIT TO MANAGER", it opens the view form for
'hr.expense.sheet' that trigger an onchange on employee_id to set the
employee's private address to the expense.
Since restricted users can't read that field, the rpc call to that onchange
was throwing an error resulting in:
1. Showing an read error when entering form view that user could close to
save anyway.
2. The hr.expense.sheet address would not be set as it should have
Now, we give sudo rights to read that field during the onchange
OPW-815786
Purpose
=======
Unbreak consistency check:
- on creation (check not done)
- when applied to a record set of several sheets belonging to different employees (reporting spurious errors)
Specification
=============
- self.something() in a api.model method does not make sense, so I replaced it with a call on the newly created sheet.
- Iterate on sheets instead of mapping all the lines
Purpose
=======
Employee must match on sheet and lines
Since the employee_id field of hr.expense.sheet is modifiable in submit state, there is a possibility to modify a sheet in such a way that the employee does not match on the expense sheet and expense lines. This commit fixes this.
- Create an expense paid by employee
- Create an expense paid by company
- Select the two expenses and submit a report
You are authorized to create this report but you cannot validate it and
you cannot refuse it because of the mix of an expense paid by employee
and paid by company. You're blocked.
We should block the creation of an expense report mixing expenses paid
by company and paid by employee
opw-783395
The groups were set only on the view which does not prevent abuses.
The fact that users can bypass the groups on the view is not critical as the
changes are logged but this should be improved nevertheless.
In master, proper record rules should be set.
Closes#20427
The ORM doesn't automatically link subrecords when it receives an
update command for a one2many. However, it may be necessary when
the default_get returns existing records for a one2many field. It
only worked before this rev. for the hr_expense model because of an
hack from 2016 (to reproduce: go to Expenses, check some expenses
from the list view, in Actions, click on 'Submit to Manager', the
new hr_expense_sheet contains the checked expenses (one2many), and
the webclient only sent an update command by linked subrecord).
This rev. fixes the problem properly: when the default_get returns
existing subrecords for a one2many field, a link_to command (4) is
generated alongside the update (1) command.
- Set 'Tax calculation rounding method' to 'Round Globally'
- Create a expense product with a tax of 20% included in the price
- Create a expense of 19.99
- Submit the expense in a expense sheet
- Validate the expense
- Post the expense
- Register a payment of 19.99
The expense is not set as paid.
The source of the issue is that the tax line is created without being
rounded. In the specific example, two lines are created with amounts:
- 16.658
- 3.33166667 (Tax)
This introduces rounding error in the computation of the matched
percentage, and the expense is not set as paid.
We force the rounding of the taxes since the 'Round Globally' option has
no impact on an expense report.
opw-773908
Purpose
=======
Currently, if we want to print an expense report that has several currencies in its expense lines, the total amount is hidden on the report. Otherwise, it is simply summed.
That could lead to confusing uses cases. Example.
1 expense line of 92 dollars.
1 expense report expressed in euros.
In the report we will have
- 1 line of 92 dollars
- Total amount: 92 euros
Which is obviously wrong.
Specification
=============
Always display the amount + Compute the amount in the expense report currency, by converting the amount with the rate at the day the expense has been made.
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.
Nicolas Lempereur