Thursday, April 22, 2021
21 changes · master
Enhancements to existing features
This update streamlines how Odoo handles internal fields on abstract models by avoiding fields that are not useful there. It helps prepare the system for future performance and maintainability improvements without changing day-to-day user workflows.
Original PR description
Magic and inherited fields are not really useful on abstract models. The _inherits specification is used anyway by models that inherit from those abstract models. The main goal of this change is to prepare a refactoring of models where fields are no longer duplicated on the registry classes, but fields defined on classes are used directly. But this new design cannot be applied to all fields: a field being overridden simply cannot be used directly. This branch improves the situation by avoiding unnecessary field overridings.
Miscellaneous changes
Steps to reproduce the bug: - Let's consider a consumable product P with a subcontracted BOM B - Let's consider that B is subcontracted by a partner S and B has a storable component C - C has the route Resupply Subcontractor on Order and has a partner SUP as supplier - Create a purchase order PO with 1 P to S and confirm PO - A delivery order DO1 is created with C to S - Change the ordered quantity on PO and set 2 instead of 1 Bug: DO1 was canceled and a new delivery order DO2 was
Original PR description
Steps to reproduce the bug: - Let's consider a consumable product P with a subcontracted BOM B - Let's consider that B is subcontracted by a partner S and B has a storable component C - C has the…
Steps to reproduce the bug: - Let's consider a consumable product P with a subcontracted BOM B - Let's consider that B is subcontracted by a partner S and B has a storable component C - C has the route Resupply Subcontractor on Order and has a partner SUP as supplier - Create a purchase order PO with 1 P to S and confirm PO - A delivery order DO1 is created with C to S - Change the ordered quantity on PO and set 2 instead of 1 Bug: DO1 was canceled and a new delivery order DO2 was created with only 1 C instead of 2 It happens due to merge move, when updating the PO line a new rule is trigger and create the object in this order: - Move Sub-Stock(finished) -> Subcontract Order -> Move Stock-Sub(comp) Then the action_confirm is trigger and will run _merge_move on object from left to right order. But when the move Sub-Stock is merged, everything is write in the first move and the new move is unlink. It result by canceling all the following object (so the new subcontractor and the Move Stock-Sub). It was not an issue for the subcontracting since the write of stock.move is overridden in order to update the order quantity when the move quantity is updated. However in this case the rule are not triggered in order to create the moves that ressuply the subcontractor. In order to avoid this mess, this PR prevent the merge in case of a subcontracting move. opw-2419222 X-original-commit: 48f2bbb844502c91dce59e8d869b56df0960fd0a Co-authored-by: simongoffin <sig@odoo.com> Forward-Port-Of: odoo/odoo#68996
Issue 1: Concurrent synchro --------------------------- Each time the calendar view of event.calendar is loaded, the synchronization with google calendar was launched and if a user open many tabs, it can lead to deadlock Solution: Check for lock before launching the synchro, if the transaction cannot acquire the lock, it's probably because another synchro already started Issue 2: Write on deleted record -------------------------------- The delete operation, like other operation, se
Original PR description
Issue 1: Concurrent synchro --------------------------- Each time the calendar view of event.calendar is loaded, the synchronization with google calendar was launched and if a user open many tabs, it can lead to deadlock Solution: Check for lock before launching the synchro, if the transaction cannot acquire the lock, it's probably because another synchro already started Issue 2: Write on deleted record -------------------------------- The delete operation, like other operation, set need_sync = False Obviously, when the record are already deleted in odoo it's not needed and possible anymore and thus raise an exception -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#66403
Dropdown menus (eg.: font-size) had their contents cropped if space was lacking underneath the toolbar. With this the user can scroll down to see the rest of it if needed. More info: twbs/bootstrap#23378 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69638
Original PR description
Dropdown menus (eg.: font-size) had their contents cropped if space was lacking underneath the toolbar. With this the user can scroll down to see the rest of it if needed. More info: twbs/bootstrap#23378 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69638
Usecase to reproduce: - BOM PROD 1 -> No operation -> KIT COMP 1 - BOM KIT COMP 1 -> at lease one operation Create a MO and confirm it -> Traceback. It happens because workorders_by_bom[production.bom_id] will try to find the bom related to production order. However they don't exist but it will create the entry [BOM PROD 1] = mrp.workorder() The [0] will be call on each values of the list afterward and raise the traceback opw-2477269 Forward-Port-Of: odoo/odoo#68975
Original PR description
Usecase to reproduce: - BOM PROD 1 -> No operation -> KIT COMP 1 - BOM KIT COMP 1 -> at lease one operation Create a MO and confirm it -> Traceback. It happens because workorders_by_bom[production.bom_id] will try to find the bom related to production order. However they don't exist but it will create the entry [BOM PROD 1] = mrp.workorder() The [0] will be call on each values of the list afterward and raise the traceback opw-2477269 Forward-Port-Of: odoo/odoo#68975
Courtesy of @willmakenoise Commented on commit ae7e1f64f8f4d7bfe21f329721eb1bb21d0593d1 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69640
Original PR description
Courtesy of @willmakenoise Commented on commit ae7e1f64f8f4d7bfe21f329721eb1bb21d0593d1 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69640
In mass mailing edition, in some configuration of: - being in a modal or not - size of window - zoom level we might get an error when getting the scrolling element. For example when editing a mass mailing, if I set my viewport to 595 pixels height and have a 90% zoom, the editor is broken. This is because in SnippetsMenu.starts `$().getScrollingElement()` doesn't find an element that has the height of body. In my use case body height is 329.111 pixels, and scroll height is 328 pixels. Test
Original PR description
In mass mailing edition, in some configuration of: - being in a modal or not - size of window - zoom level we might get an error when getting the scrolling element. For example when editing a mass mailing, if I set my viewport to 595 pixels height and have a 90% zoom, the editor is broken. This is because in SnippetsMenu.starts `$().getScrollingElement()` doesn't find an element that has the height of body. In my use case body height is 329.111 pixels, and scroll height is 328 pixels. Testing different zoom level and viewport height, the maximum difference I was able to get was 1.25 so this commit increase to 1.5 the maxmimum difference. opw-2455727 opw-2469174 Forward-Port-Of: odoo/odoo#69592
Method `_onchange_workorder_ids` will create workorder_ids for the the selected bom but it was not re-setting it on removing BoM. It was causing issue on `_action_confirm` as Bom for the selected WO will not be found. Fixes: #68261 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 Forward-Port-Of: odoo/odoo#69564
Original PR description
Method `_onchange_workorder_ids` will create workorder_ids for the the selected bom but it was not re-setting it on removing BoM. It was causing issue on `_action_confirm` as Bom for the selected WO will not be found. Fixes: #68261 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 Forward-Port-Of: odoo/odoo#69564
What are the steps to reproduce your issue ? 1. Add a coupon program with the following condition sale_ok == True & name == 'Large Desk' 2. Add 'Buy 1 get 2 free' 'Large Cabinet' 3. Create a quotation with 1 Large Desk and 2 Large Cabinet 4. Add the coupon code What is currently happening ? Promotion will only remove one * Large Cabinet price instead of 2 What are you expecting to happen ? Promotion remove two * Large Cabinet price Why is this happeni
Original PR description
What are the steps to reproduce your issue ? 1. Add a coupon program with the following condition sale_ok == True & name == 'Large Desk' 2. Add 'Buy 1 get 2 free' 'Large Cabinet' 3. Create a…
What are the steps to reproduce your issue ?
1. Add a coupon program with the following condition sale_ok == True & name == 'Large Desk'
2. Add 'Buy 1 get 2 free' 'Large Cabinet'
3. Create a quotation with 1 Large Desk and 2 Large Cabinet
4. Add the coupon code
What is currently happening ?
Promotion will only remove one * Large Cabinet price instead of 2
What are you expecting to happen ?
Promotion remove two * Large Cabinet price
Why is this happening ?
Because there is a filter that applies before the calculation of the number of free articles obtained is done.
This filter only keeps the products that match the condition of the coupon: the product that must be purchased in order to benefit two free items.
In our example this filter just keeps Large Desk, which is the item you have to buy to get 2 Large Cabinet.
The calculation is not done correctly because it only has 1 Large Desk,
and will apply the promotion for 1 Large Cabinet
How to fix the bug ?
Remove this first filter
opw-2496940
Forward-Port-Of: odoo/odoo#69626
Forward-Port-Of: odoo/odoo#69365On a product's Forecasted Report page, if the company has a lot of warehouses, when the user opens the drop-down list to select another warehouse, the list will exceeds the window height and won't be scrollable. The user will have to zoom out to see the rest of the list. `o_dropdown_menu` class is used to add required attributes: https://github.com/odoo/odoo/blob/a622936ab09497086f43715e546a1b33418d0ee3/addons/web/static/src/scss/dropdown_menu.scss#L7-L8 OPW-2480784 Forward-Port-Of: o
Original PR description
On a product's Forecasted Report page, if the company has a lot of warehouses, when the user opens the drop-down list to select another warehouse, the list will exceeds the window height and won't be scrollable. The user will have to zoom out to see the rest of the list. `o_dropdown_menu` class is used to add required attributes: https://github.com/odoo/odoo/blob/a622936ab09497086f43715e546a1b33418d0ee3/addons/web/static/src/scss/dropdown_menu.scss#L7-L8 OPW-2480784 Forward-Port-Of: odoo/odoo#69523
Steps to reproduce the bug: - Let's consider a journal J with inbound payment methods PM1 and PM2 - Create an inbound batch payment with Bank = J - The default payment method will be PM2, change it to PM1 - Create a payment P in the batch content (payment_ids) - Save Bug: A UserError was raised: The batch must have the same type as the payments it contains. because when setting a partner on P the function _compute_payment_method_id defined in module acco
Original PR description
Steps to reproduce the bug:
- Let's consider a journal J with inbound payment methods PM1 and PM2
- Create an inbound batch payment with Bank = J
- The default payment method will be PM2, change it to PM1
- Create a payment P in the batch content (payment_ids)
- Save
Bug:
A UserError was raised: The batch must have the same type as the payments it contains.
because when setting a partner on P the function _compute_payment_method_id defined in module account_check_printing
was triggered and the first available payment method was set.
opw:2495487
Forward-Port-Of: odoo/odoo#69252Same reason that cdb7a8ad7647649ad8f595454aa9dc0464117568 The tour bubble animation might cause the page to flicker since the scrollbar might appear disappear depending on size of modal / browser. opw-2469248 Forward-Port-Of: odoo/odoo#69596
Original PR description
Same reason that cdb7a8ad7647649ad8f595454aa9dc0464117568 The tour bubble animation might cause the page to flicker since the scrollbar might appear disappear depending on size of modal / browser. opw-2469248 Forward-Port-Of: odoo/odoo#69596
A colorpicker in an option positioned above the toolbar in a snippets menu would be hidden by the toolbar because of the toolbar's z-index. That z-index is only needed when the editor is in a modal. The bug this commit fixes only arises when the toolbar is in a snippets menu. This applies the z-index only when there is a snippets menu in the page. To accomplish that we need the "editor_has_snippets" class that the website module applied to the body. For the sake of harmony within Odoo, that c
Original PR description
A colorpicker in an option positioned above the toolbar in a snippets menu would be hidden by the toolbar because of the toolbar's z-index. That z-index is only needed when the editor is in a modal. The bug this commit fixes only arises when the toolbar is in a snippets menu. This applies the z-index only when there is a snippets menu in the page. To accomplish that we need the "editor_has_snippets" class that the website module applied to the body. For the sake of harmony within Odoo, that class is now applied by snippets.editor so that no matter the module, if there is a snippets bar, the class is on the body of its document. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69653
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 Forward-Port-Of: odoo/odoo#69498
Original PR description
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 Forward-Port-Of: odoo/odoo#69498
This fixes a bug in mass mailing, that made the toolbar still visible while the selection was not in an editable area. It was due to a jquery selector targetting the top document instead of the iframe's document. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69676
Original PR description
This fixes a bug in mass mailing, that made the toolbar still visible while the selection was not in an editable area. It was due to a jquery selector targetting the top document instead of the iframe's document. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#69676
previous_report_number must contain only 0s when not set. Forward-Port-Of: odoo/enterprise#17885
Original PR description
previous_report_number must contain only 0s when not set. Forward-Port-Of: odoo/enterprise#17885
Forward-Port-Of: odoo/enterprise#17850
Original PR description
Forward-Port-Of: odoo/enterprise#17850
The field type name is translated, but the check is only against english (and french by chance). note: also fix the same type of issue for code that doesn't display "Text" or "Multiline Text" placeholder is the default value ("Text" and "Multiline Text"). opw-2477371 Forward-Port-Of: odoo/enterprise#17859
Original PR description
The field type name is translated, but the check is only against english
(and french by chance).
note: also fix the same type of issue for code that doesn't display
"Text" or "Multiline Text" placeholder is the default value ("Text" and
"Multiline Text").
opw-2477371
Forward-Port-Of: odoo/enterprise#17859The last step of the approvals tour clicks on the `submit` button but does not wait for the result. As a consequence, the python test is considered as finished but some requests may still to occur, depending of the speed. For example, if the chrome browser is quickly killed, before anything else happens, there are no remaining requests. In that case, the last step can be considered as useless as it does not trigger anything server side. But when the browser is killed to late, there co
Original PR description
The last step of the approvals tour clicks on the `submit` button but does not wait for the result. As a consequence, the python test is considered as finished but some requests may still to occur, depending of the speed. For example, if the chrome browser is quickly killed, before anything else happens, there are no remaining requests. In that case, the last step can be considered as useless as it does not trigger anything server side. But when the browser is killed to late, there could be up to 5 remaining requests. Worst, in some rare cases, some of them are not waited by the HttpCase and may interfere with another test. It happens on runbot, makeing the portal tour fail: https://runbot.odoo.com/runbot/build/7213084 But this particular case is part of another investigated issue. Forward-Port-Of: odoo/enterprise#17856
…s amount Forward-Port-Of: odoo/enterprise#17756
Original PR description
…s amount Forward-Port-Of: odoo/enterprise#17756
When the users checks his tickets on portal, if he adds a 'group by' filter and then selects another page, the 'group by' filter will be ignored. OPW-2488408 Forward-Port-Of: odoo/enterprise#17819
Original PR description
When the users checks his tickets on portal, if he adds a 'group by' filter and then selects another page, the 'group by' filter will be ignored. OPW-2488408 Forward-Port-Of: odoo/enterprise#17819