Wednesday, May 29, 2024
12 changes · saas-17.2
Miscellaneous changes
Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203 Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce: - Create a kit with components Uom set as Kg - Create an SO for the kit using packaging - Validate the delivery and try printing the delivery slip ERROR Bug: when generating the delivery slip we convert movelines qty to the packaging Uom but in the case of a kit the movelines are those of the components (in this we're converting Kg to units) Fix: Ignore kit lines (will be removed any way in _get_aggregated_product_quantities) opw-3758203 Forward-Port-Of: odoo/odoo#166717 Forward-Port-Of: odoo/odoo#161920
steps to reproduce: - create a PO and buy 10 units of acoustic bloc screens from Azure interior - validate PO and picking (you now have qty_received=10 on the PO line) - create a return of 25 units and validite the picking (qty_received=-15) - change the PO line quantity to a negative amount (ex: -3) => ``` File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_pick
Original PR description
steps to reproduce:
- create a PO and buy 10 units of acoustic bloc screens from Azure interior
- validate PO and picking (you now have qty_received=10 on the PO line)
- create a return of 25 units and validite the picking (qty_received=-15)
- change the PO line quantity to a negative amount (ex: -3)
=>
```
File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 392, in write
lines.with_context(previous_product_qty=previous_product_uom_qty)._create_or_update_picking()
File "/data/build/odoo/addons/purchase_stock/models/purchase.py", line 445, in _create_or_update_picking
line.invoice_lines[0].move_id.activity_schedule(
File "/data/build/odoo/odoo/models.py", line 5952, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
opw-3941103
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#166245Some live chat sessions are available as demo data. Some of these sessions had incorrectly crafted messages, leading to small visual glitches. For exemple, some messages were missing their `subtype_xmlid`, resulting in emojis being displayed with an incorrect margin. Others assigned the `message_type` field twice. This PR fixes this issue. task-3850900 Before:  After:  After:  Forward-Port-Of: odoo/odoo#167063
Before this commit: ========== - After scanning the product barcode, the notification of the added product was not showing in mobile mode. After this commit: ========== - After scanning the product barcode, the notification of the added product will work fine. task-3877329 Forward-Port-Of: odoo/odoo#166930 Forward-Port-Of: odoo/odoo#164272
Original PR description
Before this commit: ========== - After scanning the product barcode, the notification of the added product was not showing in mobile mode. After this commit: ========== - After scanning the product barcode, the notification of the added product will work fine. task-3877329 Forward-Port-Of: odoo/odoo#166930 Forward-Port-Of: odoo/odoo#164272
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click invite - Choose any template - You can't scroll inside the template Origin of the issue: ==================== Many other apps inherits the view with id `view_mail_mass_mailing_form` and not the view with id `mailing_mailing_view_form_full_width` which have the logic of resizing the ifra
Original PR description
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click…
Issue: ===== We can't scroll in iframe using the mouse (no scroll available) Steps to reproduce the issue: ============================= - Install events, mass_mailing - Go to any event and click invite - Choose any template - You can't scroll inside the template Origin of the issue: ==================== Many other apps inherits the view with id `view_mail_mass_mailing_form` and not the view with id `mailing_mailing_view_form_full_width` which have the logic of resizing the iframe to the length of its content (introduced here [1]) so we don't really need to scroll inside the iframe. But for the other apps since they inherit from the first mentioned view, they will have the iframe class `.o_mass_mailing_iframe` but we specified in mass_mailing.ui.scss file that html that have that class we don't assign `overflow:visible` to them , that's why we can't scroll inside the iframe. Solution: ========= There are a lof of ways to solve this problem but most of them needs an xml change which requires an update of the module. The current solution is to add a special class to the full_width view using js from it's already defined js_class and then we exclude it from the scss selector. opw-3897165 [1]: https://github.com/odoo/odoo/commit/8a74c1f79340c58d62c9577f1011d9dc6a58ff70 Forward-Port-Of: odoo/odoo#164666
 This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513. Forward-Port-Of: odoo/odoo#165034
Original PR description
 This `next_serial` argument was added in https://github.com/odoo/odoo/pull/117513. Forward-Port-Of: odoo/odoo#165034
Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view. 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#167051
Original PR description
Commit 9ca10649b857f8ba4d7f212200a64f98d5e8582b corrected the opening of the "detailed operation for subcontracting stock moves but uses a wrong icon to display in the list view. 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#167051
Where : In Point of Sale > Configuration > Settings The category "Product & PoS catefories" was misspelled and is corrected to "Product & PoS categories" opw-3923475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165243
Original PR description
Where : In Point of Sale > Configuration > Settings The category "Product & PoS catefories" was misspelled and is corrected to "Product & PoS categories" opw-3923475 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165243
Before this commit, you can delete an user linked to an employee without any warning. With this constraint, you need to manually remove the user on the employee record, so it cannot be done by accident. Forward-Port-Of: odoo/odoo#166619 Forward-Port-Of: odoo/odoo#166516
Original PR description
Before this commit, you can delete an user linked to an employee without any warning. With this constraint, you need to manually remove the user on the employee record, so it cannot be done by accident. Forward-Port-Of: odoo/odoo#166619 Forward-Port-Of: odoo/odoo#166516
# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:----
Original PR description
# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 650ms | 600ms | | 91 | 1min26 | 9s | | 273 | 4min50 | 34s | | 405 | 7min13 | 55s | # Fix: Batch more actions and records to reduce the number of queries generated by the ORM. # Reference: opw-3690875 Forward-Port-Of: odoo/odoo#166728 Forward-Port-Of: odoo/odoo#151526
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161821
Original PR description
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161821
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company. Steps ----- - Create a new project, say P, with the company field set to empty. - From company A, create a new service product, say R, that creates a tas
Original PR description
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in…
Issue ----- When sale orders related to a project (through service products) are counted, `_compute_sale_order_count` aggregates on `sale_order.order_id`. However, this is not done on sudo, so in multi-company setups, a user from a company won't be able to access `sales.orders` related to the same project but from another company. Steps ----- - Create a new project, say P, with the company field set to empty. - From company A, create a new service product, say R, that creates a task in the project P. - From company A, create a sales order with the product R. - From company B, create a new service product, say Q, that creates a task in the project P. - From company B, create a similar sales order with the product Q. - From company B's sales order, click on the project smart button. - An access issue occurs as company B's user isn't able to compute `sale_order_count`. Cause ----- Not using sudo when computing `sale_order_count` through aggregating on `_compute_sale_order_count`. Solution -------- Although the `compute_sudo` can be used on `sale_order_count` & `sale_order_line_count` field definitions, it is more clear and secure to use sudo specifically on the compute function. opw-3850932 Forward-Port-Of: odoo/odoo#166769 Forward-Port-Of: odoo/odoo#163357