Steps to reproduce the bug:
- Let's consider a product P with a BOM in kit
- Create a PO with P and confirm it
- Cancel the shipment and the PO
- Reset to draft the PO and confirm it
- Valide the new shipment and receive P
Bug:
The qty_received was not updated
opw:1904678
Create a coupon/promotion that gives a 100% discount on some digital product.
If the total of the order is 0, then the client won't have the possibility
to download the product(s), since the download links appear on invoiced lines;
and no invoice has been created.
We display the download link on the products if the order total is 0,
as the other cases are already covered by the existing code.
opw 1905682
closesodoo/odoo#28799
By removing the `.id` from the `partner_id.id` domain leaf,
the ORM avoids to do a useless `SELECT` to read
the id of all partners different from the public partner,
as it already got the information from the `sale_order` table
e.g
Here is the SQL request before the revision:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
Here it is after:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" != %s)) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
closesodoo/odoo#28927
The adaptation to Python 3 was done with two mistakes: the iteration on the lru
cache does not return keys, and functions are not sortable.
closesodoo/odoo#28870
For a SO of 300 lines, when confirmed, it takes 195s to process stock
moves for the SO, which is an insane amount of time for any kind of
process in Odoo.
This happens because stock.move is a heavy model with lots of fields,
prefetching all these fields at once can hinder performance when
processing a lot of stock.moves.
To reduce the processing time, the prefetching is disabled in the
specific scenario of processing stock moves and pickings on SO
confirmation.
This patch increases the performance of SO validation (with stock
installed) by ~30%.
Pre-patch: 195s (300 SOL)
Post-patch: 135s (300 SOL)
closesodoo/odoo#28835
With the purchase module, when you create a new vendor, you can
select what variant of the product the vendor sells. The droplist
has the "Create & Edit" button to quickly create/edit variants.
This is not the wanted behavior. This PR removes the "Create & Edit"
suggestion.
opw-1909009
closesodoo/odoo#28845
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closesodoo/odoo#28766
The POS js tests expect the "Public Pricelist" when
selecting a lambda customer in the pos interface.
Nevertheless, when installing a localization
with a specific currency,
other than the currency of the public pricelist,
it creates a new pricelist called
"Default %(currency)s pricelist for %(company)s"
and sets it by default for the customers sale pricelist.
See
https://github.com/odoo/odoo/commit/787e1037cdca48fe361ae65d790056a3d57e6b67#diff-840bfc6fc7a986fbf0e248c83d2ac1d5R57
Therefore, in the POS js tests, the pricelist selected
when selecting a lambda user was no longer
'public pricelist' but the one mentioned above,
and the tests therefore failed.
The issue is solved by creating a dedicated "Public Pricelist"
for the purpose of these tests, and sets it by default
for the customer sale pricelist,
as well as for the pos config default pricelist.
The test case was to install `l10n_pe` with `point_of_sale`
while activating the test.
e.g. `-i l10n_pe,point_of_sale --test-enable`
opw-1890928
opw-1910249
closesodoo/odoo#28839
- Configure the company in USD
- Set-up the POS in EUR:
Pricelist in EUR
Payment journal in EUR
Sales journal in EUR
- In the POS, sell a product (in EUR)
- Validate the session and post entries
The entry amounts are the EUR amounts, but they are posted in USD.
Long story short: nothing was foreseen to convert the amounts in the
appropriate currency.
Fixes#27175
opw-1904146
opw-1910248
closesodoo/odoo#28785
Implement the getter method in plain SQL. This makes reading company-dependent
fields 33% faster (on 20000 partners, reading 'property_product_pricelist'
takes 3700ms instead of 5500ms.)
closesodoo/odoo#28769
In the case of a One2many list view in a `<group>` tag, the 'External
Link' button of a Many2one field (which allows opening the form view) is
not visible.
The `flex: 1 0 auto;` should not be applied in the list view.
Corresponding PR in v12: #28741
opw-1903158
closesodoo/odoo#28812
Steps:
- open a modal form view from tree view first line and make a change
- open a modal from the second line and make a change
- open the second line back: the change were lost
In a given number of conditions (a many2one inside the form view, there
is a one2many in the form view not inside the tree view, ....) this
happened because:
- when we save the first line, we get onchange data for the second one
- this onchange data can't be applied before second line is loaded, but
it is saved so it can be applied if second line is ever opened
- when the second line is opened the saved change is applied => OK
- when the second line is opened a second time the saved change is
applied again, possibly overwriting posterious change => BAD
With this changeset, when the record with unapplied onchange is loaded
for the first time, the unapplied onchange is applied only once.
Added test without the change failed with:
- only 1 turtle for second partner (result: 0 not 1)
- second partner turtle is Michelangelo (result: "" not "Michelangelo")
opw-1846820
closes#28644
This field is a dependency of some computed fields, and has to be searched on
for triggering recomputations. Without the index, the creation of stock moves
becomes slower as the table grows.
closesodoo/odoo#28757
When using the media dialog, when uploading an image, the image list
refreshes itself properly. This was not the case for documents as it
was... refreshing the image list too instead of the document list. Also,
when uploading a document, it is supposed to be added in the page
directly and the media dialog is supposed to close. This feature was
broken for the same reason: the iframe system of both tabs which were
using the same name.
Bug introduced with https://github.com/odoo/odoo/commit/abde8bddf8ec45cf12aab59e95c330321158cfba
(even though is was technically wrong for the same reason before).
Closes https://github.com/odoo/odoo/pull/28722
On firefox if we do for example:
ALT+GR + [ALT+GRable ´ key]
Firefox may send keys "AltGr" and "Dead" instead of just "AltGr".
This was possibly causing caret to go a position too low when writing
speedily with diacritical marks.
opw-1903865
closes#28739
Fine tuning of this commit:https://github.com/odoo/odoo/commit/7501691da9a9dae832b7d6e78c6a5f57fc983b5c
Fields signup_token, signup_type, signup_expiration are protected
When sending a quotation (mail template 'Sales Order - Send by Email'):
the token needs to be read (and sometimes written)
opw:1907157
Create an invoice for a day, and register a payment right away
BUT choose a date in the future for that payment
Imagine a French Check. You write it, and tell your partner to cash it in
10 days later
You would enter that transaction as a temporary payment
in your own books
OPW 1893646
Before this commit, the line of the partner did not appear in the aged
report after if the report was for the date just after the invoice date
After this commit, it does
closesodoo/odoo#28728
Before this rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
Steps to reproduce the bug:
- Set decimal precision to 7 for products.
- Order 2.000000 of a product.
- Deliver 2.6791200 of the product.
- Go back to the Sales order and change the ordered quantity to 2.6791200.
Bug:
A UserError was raised: "You cannot decrease the ordered quantity below the delivered quantity."
opw:1904580
closesodoo/odoo#28674
commit c6b0d36622 introduced a wrong
domain. The readonly should be added if the show_operations is false
OR state is done AND is_locked is true.
close#28595
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28603
As the journal is mostly set in the Odoo world the _default_journal
method is not needed during create, but in case you only have
partner_id, account_id and type in vals you will have retrieved a wrong
journal in case you have an incoming invoice.
closesodoo/odoo#28635
If `description` contains an image, the loading time of the kanban view
can be rather long. Since the field is not even used in the view, it can
be removed.
opw-1915193
closesodoo/odoo#29034
The field sale_id on model stock.picking is not defined in stock module.
So the rule was wrong when sale_stock was uninstalled.
opw:1912564
closesodoo/odoo#29145
Have a company that do not have a logo.
Try to print a "PDF report" from the accounting module
Before this commit, the simple company form popped up
with the purpose of force setting a company logo
After this commit, we assume it is not necessary to have a company logo on the reports
Note, because of 733ce266ef, we cannot do a save and print
OPW 1904764
closesodoo/odoo#28617
Have a partner with children exceeding the limit of the kanban.
Edit,
Add a contact > save and quit
Save the partner
Before this commit, there was a traceback, because a check on parent_id was done to compute
the modifier readonly of the city fields in subviews
However, python onchange gets rid of parent_id because child_ids and parent_id are two faces of the same coin
And if that check were not done, we would end up in an infinite recursion
After this commit, there is no traceback, as we stop checking on parent_id in the case of paged subviews
(list and kanban) because we literally know there is one
OPW 1886320
closesodoo/odoo#27114
Steps to reproduce the bug:
- Create a product : stockable + purchase : propose a call for tenders + reordering rule (qty min 0, max 0, multiple 1)
- Create a SO for that product.
- Run the scheduler once : a requistion is generated (Purchases > Purchase > Purchase Agreements), which is normal behavior
- Run the scheduler a second time
Bug:
A new requistion was generated for the same product, by the same reordering rule
opw:1892950
closesodoo/odoo#28611
Denis Roussel