crm.lead#case_mark_won and case_mark_lost have been removed in 1414b3e56e
merged in saas-12 but later commit 0b87f76628
reference those function and was merged in saas-11
This fix also improved logging in the controllers in order to log
unexpected exception.
Use case to reproduce:
- Create a product with a BOM that use at least
twice the same component tracked by SN
- Build this product with SN 'A' and SN 'B'
- Unbuild it
-> Constraint error on duplicate SN
It happens because the unbuild order will create only
one stock.move.lots for SN A with a quantity of 2.
This commit create a stock.move.lots by quant used,
for example if the MO used 2 quants with a qty of 1
and one with lot 'A' and the other with lot 'B'. It will
create 2 stock.move.lots with lots 'A' and 'B'.
Still a know issue: If the user try to unbuild twice
the same MO it will reuse the same unbuilded componenets
than the first unbuild order.
When purchase order are created from a scheduler they always
have the same hours even if they were created at different
time. Also the procurement order that generate the purchase
order line have the same problem.
It happens because the transformation from datetime to string
use a date format and thus truncate the DEFAULT_SERVER_TIME_FORMAT
This commit use a datetime format instead the dateformat.
opw-775833
When duplictating a Journal Entry that has been created from
a new payment (accounting/purchases/payments/create), the new copy
of the Journal Entry also duplicated the already existent relationship (link)
to the payment, causing possible future conflicts in functionalities
like reports, payments, reconciliations, among others.
opw:775151
Currently when importing files, the parent left and right are recomputed on each record creation/update, which could lead to a lot a request.
This commit will defer the parent field recomputation to the end on the `load` function by recomputing the values from the MPTT and inserting directly the new values on the records.
Tested on a customer instance, this will reduce the execution time when importing a thousand stock.location from 15 minutes to several seconds.
When you cancel or split a move, it will check the propagation setting
to see if it needs to cancel or split the next move too. If this next
move is a raw material in a manufacturing order however, it does not
make sense to do this as a lot of logic is also on these moves related
to bill of material lines, workorders, ...
opw-770062
The search bar of the pipeline report page had duplicate filters. For each, there was one with "selection" widget and one without the widget.
opw-771298
Use case to reproduce:
-> Import a file with a float using a coma related to the model
(for example the product.supplierinfo/price)
It happens because the method that parse the date and float field
only compare them to the main imported model.
This commit complete the method by using a recursion on relational
model in order to also parse the relational subfields.
- 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/
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
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
That function is called when computing related fields in onchange mode.
The new implementation makes a direct access to the cache's implementation.
opw-772303
Fabien Meghazi