Discarding a new record triggers the 'history_back' action. This makes
sense if the record was discarded from a normal form view, but not so
much when in a modal, where the expected behaviour is to close the
dialog.
This commit overrides the function in the action manager which handles
the switch to the previous view. It checks whether a dialog window is
open, in which case it simply closes it.
Before this commit, the widget many2many_tags only loaded the first 40
records. This was difficult to see, because there were not so many views
with a lot of tags.
Before this commit, there was a bug when creating a new record which
contains a one2many with an onchange. The commands sent to the onchange
did not contain the full information.
Here is how you could reproduce the issue: install expense, go to the
expense list view, select the 2 lines, then, in the 'action' menu in the
control panel, choose 'Expense: submit to manager'. In the new expense
sheet, you could see that there were two lines in the one2many
expense_line_ids. However, these lines are empty. The reason is that
the commands sent in the onchange were 2 commands 0, with {} as data.
So, in short, the BasicModel did generate the proper commands, but with
empty data, in the specific case when we have a non empty one2many in a
default_get, then an onchange.
To solve this issue, I had to fix 2 things: the internal data struture
was wrongly updated, and the commands should be generated with all the
data, and not only the changes.
Before this commit, m2o external button was always floating outside the
m2o main DOM element, on the right. This induced problems when using the
m2o outside of views (like in Odoo Studio). Now, the m2o design is made
so that this button is inside the m2o, except in form views where we
expect the button to overflow in the tables' right paddings.
- Create 2 companies A & B (not linked)
- Create a user Demo allowed in both companies
- Create a Sale Layout Category ('TEST')
- In company A, create a SO and add 'TEST' to the line
- Switch to company B, create a SO and add 'TEST' to the line
- In the Sale Layout Category, change the sequence of 'TEST'
An access error appears.
On a SO, `layout_category_sequence` is a stored related. It means that
when we change the sequence of the layout, all SO are updated, including
the SO to which we don't have access (in this case, the SO of company A,
since our user has switched to company B).
While it seems that `layout_category_sequence` was intended to be used
in order to keep the historic value of the sequence, this is not the
actual behavior. Indeed, the method `order_lines_layouted` uses the SO
lines in their original order, which doesn't use
`layout_category_sequence`.
In summary, this related field causing an access error is never used.
opw-774787
Without instantiating the moment it will throw errors to some users.
Desired behavior after PR is merged: No longer undefined errors for end users
Fixes#18994Fixes#18618
Purpose
=======
Currently all the possible routes for /jobs are put in the sitemap.
Each time you create a job, you add at least 250 links in the sitmap (The country can be set on the route)
Specification
=============
This commit backports the behavior of this commit in v11.0 (https://github.com/odoo/odoo/commit/1b52b00d2aa96b9360d50a0f0960f1febb5e607e)
Don't generate sitemap entries for other routes than /jobs/
The parsing of the integers does not escape the thousands separator.
issue: Integers are currently not properly parsed. For example, create
a database in Spanish language, install product_expiry and in settings
activate Lots & Serial Numbers. Go to Products and create a new product.
Choose to track by lots and specify the use_time, life_time, etc.
When saving, all integers are set to 0
When registering a payment for an expense sheet with several expense lines, only
the first line of the expense sheet was linked to the account move line of the payment.
So the payment was considered as partially reconciled.
Now when a payment is registered for an expense sheet with several expense lines,
the user is redirected to the manual reconciliation widget to link the move line of
the payment to all the expense lines. In this way, the payment will be considered as fully
reconciled.
DO NOT FORWARD-PORT! ONLY FOR v10
opw:772505
When a product has multiple company taxes and b2c prices is enabled, price is
not computed properly and adds to the base price every company tax present.
This patch filters the company set on the company so taxes are computed just
for that company.
Part of the button was hidden by the (invisible) right column content
when using some particular themes.
This is because of a messy XML structure that cannot be safely repaired
in a stable version. This commit fixes the bug with CSS.
Note: this may need to be backported to 9.0 and the XML structure should
be improved in master.
Prefetching is underused when all fields are traversed one record at a time.
So instead, traverse all records one field at a time. This guarantees batch
prefetching/computation on every field being accessed.
- 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
- Create 2 companies: A is parent of B.
- Demo is in Company A
- Create 2 invoices for a partner: one in A, one in B (100 each)
- Validate the invoices
Connected as Demo, the 'Invoiced' amount on the partner form view (stat
button) is 100, while clicking on it shows both invoices (total of 200).
There is no need to manually add the company in the `where` clause since
the `_apply_ir_rules` will take care of adding the appropriate
multi-company rules.
opw-772479
Otherwise if a record rule is defined on a x2many field on the model, the creation will fail because
ir.translation creation check access rules on the model and in this case, the x2many relation are
not set yet.
Steps to reproduce the bug:
Let's consider a product A with a price of 100
Let's consider a pricelist P with a visible discount of 50% on product A.
Let's consider a quotation template Q with one line with the product A with 50%
of discount.
Let's create a SO with pricelist P and set the quotation template Q on it.
Bug:
The unit price of A on SO is 50 instead of 100 and the visible discount is 50%
instead of 75%.
With the fix:
The unit price is 100 and the discount is 75%
opw:771996
This field can be called on an hr.expense for onchange on an
hr.expense.sheet record, thus the recordset could be a virtual ID so
self.ids could be empty leading to an error.
Use case to reproduce:
- Create a picking with a package
- Go to the source or destination package
- Click on package transfers
-> It displays all the pickings
This happens because the package transfer button calls
the all picking tree view that display them.
This commit use an action instead that will add a domain
on it in order to only display the pickings that used the
selected package.
opw-774013
- Create 2 companies: A is parent of B.
- Demo is in Company A
- Create 2 invoices for a partner: one in A, one in B (100 each)
- Validate the invoices
Connected as Demo, the 'Invoiced' amount on the partner form view (stat
button) is 100, while clicking on it shows both invoices (total of 200).
There is no need to manually add the company in the `where` clause since
the `_apply_ir_rules` will take care of adding the appropriate
multi-company rules.
opw-772479
- Create a customer invoice of 100, validate
- Refund the invoice
- Go to Accounting > Reports > Business Intelligence > Invoices
- A total of 200 is shown, while it should be 0.
- The same occurs with a vendor bill (-200 instead of 0)
The invoice lines have their sign modified at two places when used in
the report:
- in method `_compute_price` of `account.invoice.line`
- in method `_from` of `account.invoice.report`
The signs are computed with the following combination:
|Invoice type|`_compute_price`|`_from`|Report sign|
|------------|----------------|-------|-----------|
|out_invoice | +1| +1| +1|
|in_invoice | +1| -1| -1|
|out_refund | -1| -1| +1|
|in_refund | -1| +1| -1|
This is not correct: out_invoice and out_refund should have opposite
signs. Same applies to in_invoice and in_refund.
opw-772479
Closes#19954
- Set up a journal which only accepts SEPA payments
- Import a CAMT file which contains a statement containing:
No "Ustrd" data
A "AddtlNtryInf" description longer than 140 characters
- Reconcile the bank statement
A contrain is raised because the communication of the SEPA payment is
longer than 140 characters.
From commit https://github.com/odoo/enterprise/commit/ff84f8b7,
"AddtlNtryInf" is used if "Ustrd" is empty. However, "AddtlNtryInf" and
"Ustrd" do not have the same restrictions. "Ustrd" can have a maximum of
140 characters, while "AddtlNtryInf" can have a maximum of 500
characters.
opw-772009
Khoi Nguyen