Wednesday, August 14, 2024
21 changes · saas-17.2
Resolved issues and error corrections
This fixes an issue where Odoo could treat the same page address as different when URL options appeared in a different order. Users should see cleaner browser navigation behavior, especially when enabling debug assets, without repeated entries for the same page.
Original PR description
When on the main menu, `/odoo?cids=1`, if you activate the debug assets, the router will push a new key (debug) into the query string : `/odoo?cids=1&debug=assets`. To fully activate the debug, a…
When on the main menu, `/odoo?cids=1`, if you activate the debug assets, the router will push a new key (debug) into the query string : `/odoo?cids=1&debug=assets`. To fully activate the debug, a reload will be done. After the reload, the action service will push the new loaded state (the menu), taking into account the locked keys (in this case: `cid` and `debug`), which will inverse the order of the query string : `/odoo?debug=assets&cids=1`. This occurs because, the order of the keys on the query string will depend on: the push order; if the keys are locked keys or not; and of the kind of push state (replacement or simple push state). The issue with this almost "random" order of the keys, is that the router could push the same URL (with keys in different order) multiple times into the browser history. Before this commit, to compare the actual URL with the new one, we just compare the two strings, and if the order of the query strings are not the same the URLs are considered as different. This commit, will avoid this issue by deep comparing the query string as objects, so when just a difference of order exists in the query string, they will be considered as the same URL. opw-3557575
Loaded signatures now display without being stretched inside the signature field. This keeps signatures looking natural and professional on signed documents, improving the signing experience.
Original PR description
Before this commit: When loading a signature, the displayed image would be stretched to fit the signature box, messing up the ratio between width and height. This commit aims to fix this issue by: keeping the same ratio between width and height. and just multiply both of them by the same factor. Task: 4049758 Before:   After:  
Miscellaneous changes
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
#### [FIX] stock_barcode: restrict product scan pckging > #### How to reproduce: > - Create a product with a product packaging and set a barcode for this packaging; > - In the Receipts operation type config, check the product mandatory scan; > - Create and confirm a receipt for the created product; > - Open the receipt in the Barcode app; > - Scan the product's packaging => A notification asks you to scan the product first. > > This behavior is not right, a packaging should be a valid s
Original PR description
#### [FIX] stock_barcode: restrict product scan pckging > #### How to reproduce: > - Create a product with a product packaging and set a barcode for this packaging; > - In the Receipts operation type…
#### [FIX] stock_barcode: restrict product scan pckging > #### How to reproduce: > - Create a product with a product packaging and set a barcode for this packaging; > - In the Receipts operation type config, check the product mandatory scan; > - Create and confirm a receipt for the created product; > - Open the receipt in the Barcode app; > - Scan the product's packaging => A notification asks you to scan the product first. > > This behavior is not right, a packaging should be a valid scan too for product's mandatory scan. > > [OPW-4062460](https://www.odoo.com/odoo/project/49/tasks/4062460?cids=1) ### [FIX] stock_barcode: GS1 packaging with lot > #### Steps to reproduce: > - In Inventory settings, choose GS1 as barcode nomenclature and activate packages; > - Create a storable product tracked by lot; > - Create a lot for this product (e.g.: 12345); > - Create a second storable product tracked by lot; > - Create a new lot with the same name (12345) and a packaging on the product page with the barcode number 10000000240489; > - Go back to the barcode app and create a new delivery; > - San the barcode 01100000002404891012345 > => The line is added for the right product but the lot is missing. > > #### What happens: > When the GS1 barcode is parsed, we got a lot name and a packaging barcode, thus, we will search a lot for the scanned lot name. > To avoid fetching the wrong lot in case multiple lots have the same name (but different product), we give a filter when the lot is scanned alongside a product. > The issue here is we didn't scan a product but a packaging and we forgot to give the same filter in this case. > > [OPW-3894500](https://www.odoo.com/odoo/project/49/tasks/3894500?cids=1) ### [FIX] stock_barcode_picking_batch: reserved lot > Bug introduced by: https://github.com/odoo/enterprise/pull/63908 > > #### How to reproduce: > - Create a product tracked by lot; > - For this product, add some quantity in stock for at least two different lots; > - Create a delivery for this product, with enough quantity to reserve at least two different lots; > - Confirm it and add it into a batch; > - Open this batch in the Barcode app; > - You should have a button to display reserved lots on the product line, click on it, it will display the reserved lot AND select the first one; > - Scan a reserved lot other than the first one => The first one will be replaced by the scannned lot even if there is already another line with this lot. > > [OPW-4017945](https://www.odoo.com/odoo/project/49/tasks/4017945?cids=1) Forward-Port-Of: odoo/enterprise#68313 Forward-Port-Of: odoo/enterprise#67267
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financie
Original PR description
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financiero' as Payment Method - Confirm - On the blue popup at the top of the page, click 'process now' to get the XML in the chatter - Click preview to get the PDF - The unit prices are not the same ### Cause: Usually on the PDF the unit price with included taxes is displayed. ### Solution: Create a xpath to compute the unit price in the same way as the XML. opw-4078177 Forward-Port-Of: odoo/enterprise#67721
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product att
Original PR description
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to…
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product attribute with a value that "is_custom" - Create a storable product P with using MTO and tour CO1 and CO2 routes - Set CO2 as a vendor for the product - With CO1, create a SO for 1 unit of your product P - a popup asks you for a custom product attribute value, write "test" - Confirm the SO > Automatically creates a PO (w/ description) - Confirm the PO > Automatically create an SO in CO2 (w/ description) - Confirm the SO in CO2 > Automatically create an MO #### Issue: #### The custom description is missing on the final MO. #### Note: If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO. ### Cause of the issue: The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2. ### Fix: We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly. ### Note: As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot). opw-3998861 --- Forward-Port-Of: odoo/enterprise#67650 Forward-Port-Of: odoo/enterprise#67172
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ > Click smart button to navigate to the PO > Confirm the PO (should work) 4. Repeat step 2, ValidationError when trying to confirm the PO. Note: the issue only arises in this specific flow, the PO can still b
Original PR description
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with…
Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.
Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.
Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154
As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.
Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.
opw-3990816
Forward-Port-Of: odoo/enterprise#66504Instead of using the `bg-white` class from boostrap, which is translated to black in dark-mode, make use of the color-scheme from odoo. This avoids having a mismatch between light and dark mode. Before (Dark / Light):  After (Dark / Light):  Forward-Port-Of: odoo/enterprise#68231
Original PR description
Instead of using the `bg-white` class from boostrap, which is translated to black in dark-mode, make use of the color-scheme from odoo. This avoids having a mismatch between light and dark mode. Before (Dark / Light):  After (Dark / Light):  Forward-Port-Of: odoo/enterprise#68231
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url. Steps to reproduce: 1. Install Documents. 2. Have atleast 2 companies. 3. Create a new folder that
Original PR description
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same…
Issue: When we have multiple companies and we create different folders for each other, if we are working in a folder from let's say company A and then we switch to Company B, we will run the same link to this folder but from the Company B rights point of view, and since this folder is not accesible from this company it will throw a traceback and break the page until refresh to another url. Steps to reproduce: 1. Install Documents. 2. Have atleast 2 companies. 3. Create a new folder that belongs to the current company. 4. While having this folder selected, change to the 2nd company. Solution: The issue is triggered within the load funcion for the DocumentsSearchModel, since we get the folderId that's in the url, and we also get the list of the folder we have access to, we could filter out if the current folder we are trying to access is within this list before calling toggleCategoryValue, and If it's not we could just call it on `folderId = false;` as default (which is the "All" section of folders). This way we avoid calling `category.values.get(...)` later on for undefined (we don't have access to this folder). opw-3971935 Forward-Port-Of: odoo/enterprise#64513
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of
Original PR description
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of the method being called from the Rental app. Steps to Reproduce on Runbot: 1. Install Rental app 2. View the rental orders in list view 3. Select a rental order with a status and duplicate 4. Observe that duped rental order has no rental_status when you confirm it opw-4055493 Forward-Port-Of: odoo/enterprise#67670
Before this commit: Unhandled python traceback will be tough to read as there is too much line breaks which was forcing each line to be logged. e.g: ```py 2024-08-12 09:33:49,426 2466 ERROR ? root: Exception in thread 2024-08-12 09:33:49,428 2466 ERROR ? root: Thread-9 2024-08-12 09:33:49,429 2466 ERROR ? root: : 2024-08-12 09:33:49,430 2466 ERROR ? root: 2024-08-12 09:33:49,430 2466 ERROR ? root: Traceback (most recent call last): 2024-08-12 09:33:49,430 2466 ERROR ? root: 202
Original PR description
Before this commit: Unhandled python traceback will be tough to read as there is too much line breaks which was forcing each line to be logged. e.g: ```py 2024-08-12 09:33:49,426 2466 ERROR ? root:…
Before this commit: Unhandled python traceback will be tough to read as there is too much line breaks which was forcing each line to be logged. e.g: ```py 2024-08-12 09:33:49,426 2466 ERROR ? root: Exception in thread 2024-08-12 09:33:49,428 2466 ERROR ? root: Thread-9 2024-08-12 09:33:49,429 2466 ERROR ? root: : 2024-08-12 09:33:49,430 2466 ERROR ? root: 2024-08-12 09:33:49,430 2466 ERROR ? root: Traceback (most recent call last): 2024-08-12 09:33:49,430 2466 ERROR ? root: 2024-08-12 09:33:49,430 2466 ERROR ? root: File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner 2024-08-12 09:33:49,439 2466 ERROR ? root: 2024-08-12 09:33:49,439 2466 ERROR ? root: 2024-08-12 09:33:49,457 2466 ERROR ? root: self.run() 2024-08-12 09:33:49,459 2466 ERROR ? root: 2024-08-12 09:33:49,459 2466 ERROR ? root: File "/home/pi/odoo/addons/hw_drivers/interface.py", line 31, in run 2024-08-12 09:33:49,460 2466 ERROR ? root: 2024-08-12 09:33:49,461 2466 ERROR ? root: 2024-08-12 09:33:49,465 2466 ERROR ? root: self.update_iot_devices(self.get_devices()) 2024-08-12 09:33:49,466 2466 ERROR ? root: 2024-08-12 09:33:49,467 2466 ERROR ? root: 2024-08-12 09:33:49,467 2466 ERROR ? root: 2024-08-12 09:33:49,467 2466 ERROR ? root: 2024-08-12 09:33:49,468 2466 ERROR ? root: 2024-08-12 09:33:49,468 2466 ERROR ? root: 2024-08-12 09:33:49,468 2466 ERROR ? root: 2024-08-12 09:33:49,468 2466 ERROR ? root: 2024-08-12 09:33:49,468 2466 ERROR ? root: 2024-08-12 09:33:49,469 2466 ERROR ? root: 2024-08-12 09:33:49,469 2466 ERROR ? root: 2024-08-12 09:33:49,470 2466 ERROR ? root: 2024-08-12 09:33:49,473 2466 ERROR ? root: 2024-08-12 09:33:49,474 2466 ERROR ? root: 2024-08-12 09:33:49,474 2466 ERROR ? root: 2024-08-12 09:33:49,474 2466 ERROR ? root: 2024-08-12 09:33:49,480 2466 ERROR ? root: 2024-08-12 09:33:49,482 2466 ERROR ? root: 2024-08-12 09:33:49,487 2466 ERROR ? root: 2024-08-12 09:33:49,488 2466 ERROR ? root: 2024-08-12 09:33:49,488 2466 ERROR ? root: 2024-08-12 09:33:49,488 2466 ERROR ? root: 2024-08-12 09:33:49,488 2466 ERROR ? root: 2024-08-12 09:33:49,488 2466 ERROR ? root: 2024-08-12 09:33:49,495 2466 ERROR ? root: 2024-08-12 09:33:49,495 2466 ERROR ? root: 2024-08-12 09:33:49,496 2466 ERROR ? root: 2024-08-12 09:33:49,496 2466 ERROR ? root: 2024-08-12 09:33:49,497 2466 ERROR ? root: 2024-08-12 09:33:49,497 2466 ERROR ? root: ^ 2024-08-12 09:33:49,498 2466 ERROR ? root: ^ 2024-08-12 09:33:49,499 2466 ERROR ? root: ^ 2024-08-12 09:33:49,502 2466 ERROR ? root: ^ 2024-08-12 09:33:49,502 2466 ERROR ? root: ^ 2024-08-12 09:33:49,503 2466 ERROR ? root: ^ 2024-08-12 09:33:49,503 2466 ERROR ? root: ^ 2024-08-12 09:33:49,503 2466 ERROR ? root: ^ 2024-08-12 09:33:49,503 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,504 2466 ERROR ? root: ^ 2024-08-12 09:33:49,505 2466 ERROR ? root: ^ 2024-08-12 09:33:49,505 2466 ERROR ? root: ^ 2024-08-12 09:33:49,505 2466 ERROR ? root: ^ 2024-08-12 09:33:49,505 2466 ERROR ? root: 2024-08-12 09:33:49,505 2466 ERROR ? root: File "/home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface_L.py", line 21, in get_devices 2024-08-12 09:33:49,506 2466 ERROR ? root: 2024-08-12 09:33:49,506 2466 ERROR ? root: 2024-08-12 09:33:49,507 2466 ERROR ? root: 0/0 2024-08-12 09:33:49,507 2466 ERROR ? root: 2024-08-12 09:33:49,507 2466 ERROR ? root: 2024-08-12 09:33:49,507 2466 ERROR ? root: 2024-08-12 09:33:49,508 2466 ERROR ? root: 2024-08-12 09:33:49,508 2466 ERROR ? root: 2024-08-12 09:33:49,508 2466 ERROR ? root: ~ 2024-08-12 09:33:49,508 2466 ERROR ? root: ^ 2024-08-12 09:33:49,508 2466 ERROR ? root: ~ 2024-08-12 09:33:49,508 2466 ERROR ? root: 2024-08-12 09:33:49,508 2466 ERROR ? root: ZeroDivisionError 2024-08-12 09:33:49,509 2466 ERROR ? root: : 2024-08-12 09:33:49,509 2466 ERROR ? root: division by zero ``` After this commit: New lines are logged only if necessary, like in a regular tb: ```py 2024-08-12 09:41:06,197 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: Exception in thread Thread-9: 2024-08-12 09:41:06,199 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: Traceback (most recent call last): 2024-08-12 09:41:06,201 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner 2024-08-12 09:41:06,222 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: self.run() 2024-08-12 09:41:06,223 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: File "/home/pi/odoo/addons/hw_drivers/interface.py", line 31, in run 2024-08-12 09:41:06,233 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: self.update_iot_devices(self.get_devices()) 2024-08-12 09:41:06,234 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: ^^^^^^^^^^^^^^^^^^ 2024-08-12 09:41:06,234 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: File "/home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface_L.py", line 21, in get_devices 2024-08-12 09:41:06,235 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: 0/0 2024-08-12 09:41:06,236 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: ~^~ 2024-08-12 09:41:06,237 3093 ERROR ? odoo.addons.hw_drivers.exception_logger: ZeroDivisionError: division by zero ``` opw-4110599 Forward-Port-Of: odoo/odoo#176462
Issue: In the portal page for managing your mailing lists, to subscribe or unsubscribe, you can see also the ones that are supposely marked for not appearing in this view, when this happen the appear as "Mailing list .#number" which is not ideal, since it will still let us subscribe to it when we shouldn be able to. Stesp to reproduce: 1. Install mass_mailing. 2. Create atleast 2 lists, one with "Show in Preferences" ticked and the other not. 3. Now go to "/mailing/my" to manage the list
Original PR description
Issue: In the portal page for managing your mailing lists, to subscribe or unsubscribe, you can see also the ones that are supposely marked for not appearing in this view, when this happen the appear as "Mailing list .#number" which is not ideal, since it will still let us subscribe to it when we shouldn be able to. Stesp to reproduce: 1. Install mass_mailing. 2. Create atleast 2 lists, one with "Show in Preferences" ticked and the other not. 3. Now go to "/mailing/my" to manage the lists and see how they appear. Solution: It seems logical to filter out for the lists we are not subscribed the non public lists out (the ones that are not marked as "Show In Preferences"), with this we will only see the ones we should have access to see and subscribe/unsubscribe. opw-3877385 Forward-Port-Of: odoo/odoo#162835
This commit is a backport of odoo/odoo#173905, but for the qunit suite. This should prevent the qunit suite from running out of memory, which sometimes happens because the Chrome process running the qunit suites doesn't have access to its available memory and cannot run the garbage collection efficiently. Runbot error 53410 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
Original PR description
This commit is a backport of odoo/odoo#173905, but for the qunit suite. This should prevent the qunit suite from running out of memory, which sometimes happens because the Chrome process running the qunit suites doesn't have access to its available memory and cannot run the garbage collection efficiently. Runbot error 53410 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#176506
[IMP] l10n_pl: Credit note can't be more than the invoice total amount Polish law don't allow to have credit note with an amount higher than the invoice Solution: Don't allow to post a credit note if the total is higher than the invoice task-id#3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168252
Original PR description
[IMP] l10n_pl: Credit note can't be more than the invoice total amount Polish law don't allow to have credit note with an amount higher than the invoice Solution: Don't allow to post a credit note if the total is higher than the invoice task-id#3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168252
Steps to reproduce: - Create a product and set a quantity in a sublocation of Stock - Create a scrap order for that product - Set location as Stock (NOT the sublocation) - Validate the scrap order Issue: The insufficient quantity warning doesn't trigger anymore. The change made in [1] allowed the scrap orders to properly handle kits. To do that, it uses the product qty_available directly as it correctly handles kit components. But since we're not using the strict mode of `_gather()` a
Original PR description
Steps to reproduce: - Create a product and set a quantity in a sublocation of Stock - Create a scrap order for that product - Set location as Stock (NOT the sublocation) - Validate the scrap order Issue: The insufficient quantity warning doesn't trigger anymore. The change made in [1] allowed the scrap orders to properly handle kits. To do that, it uses the product qty_available directly as it correctly handles kit components. But since we're not using the strict mode of `_gather()` anymore, it will also look for child locations quantities, which isn't what we want for scrap orders. Added a context key to enable a strict location lookup for qty_available and uses it for scrap orders. [1] a196f947c829fde08d3ddf79b6c4f5a42a1217cd opw-4055721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174373
Combining purchase order line and product supplier info for orders with multiple pages results in inconsistent behavior: - products on first page shows the internal references and names - subsequent pages shows the supplier's codes and names. It is better to display the internals for the product field and keep the supplier codes and names for the description field. Therefore, the search has also been fixed accordingly. task: 4040598 (see also 3893787) see also https://github.com/odoo/
Original PR description
Combining purchase order line and product supplier info for orders with multiple pages results in inconsistent behavior: - products on first page shows the internal references and names - subsequent pages shows the supplier's codes and names. It is better to display the internals for the product field and keep the supplier codes and names for the description field. Therefore, the search has also been fixed accordingly. task: 4040598 (see also 3893787) see also https://github.com/odoo/odoo/pull/113527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175067
task-4104252 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#176493
Original PR description
task-4104252 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#176493
**Behaviour before PR:** When we try to add a link on an image through dialog box, image gets hidden and url is added as a link label instead. **Behaviour after PR:** Now, link can be added to the image without vanishing the image. task-4049730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176358 Forward-Port-Of: odoo/odoo#174211
Original PR description
**Behaviour before PR:** When we try to add a link on an image through dialog box, image gets hidden and url is added as a link label instead. **Behaviour after PR:** Now, link can be added to the image without vanishing the image. task-4049730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176358 Forward-Port-Of: odoo/odoo#174211
Before this commit: Invoices reconciled with a single payment appeared in a random order on the Payment Receipt. This was caused by the use of a set, which does not preserve the order of invoices. After this commit: Invoices are displayed in the order defined by the account.move model, ensuring a consistent and logical sequence. Steps to reproduce: - Create four invoices for the same customer on different dates. - Register a customer payment covering the total amount of the four invoic
Original PR description
Before this commit: Invoices reconciled with a single payment appeared in a random order on the Payment Receipt. This was caused by the use of a set, which does not preserve the order of invoices. After this commit: Invoices are displayed in the order defined by the account.move model, ensuring a consistent and logical sequence. Steps to reproduce: - Create four invoices for the same customer on different dates. - Register a customer payment covering the total amount of the four invoices. - Reconcile the payment with the invoices. - Print the Payment Receipt for the payment. opw-4096451 Forward-Port-Of: odoo/odoo#176536 Forward-Port-Of: odoo/odoo#176313
VAT validations for Costa Rica identification types according to: - CÉDULA FÍSICA: 9 digits - CÉDULA JURÍDICA: 10 digits - CÉDULA DIMEX: 11 or 12 digits - CÉDULA NITE: 10 digits Legal information is on [page 4](https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2016/v4/ANEXOS%20Y%20ESTRUCTURAS.pdf). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163923
Original PR description
VAT validations for Costa Rica identification types according to: - CÉDULA FÍSICA: 9 digits - CÉDULA JURÍDICA: 10 digits - CÉDULA DIMEX: 11 or 12 digits - CÉDULA NITE: 10 digits Legal information is on [page 4](https://atv.hacienda.go.cr/ATV/ComprobanteElectronico/docs/esquemas/2016/v4/ANEXOS%20Y%20ESTRUCTURAS.pdf). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163923
In versions v17 and up, a div with class `.o-discuss-CallInvitations` was causing issues by blocking the scrollbar's up arrow, preventing users from scrolling up. To address this, the display of the `.o-discuss-CallInvitations` div is now conditional, based on `store.discuss.ringingThreads.length > 0`. This ensures the div only appears when necessary, avoiding obstruction of the scrollbar and improving usability. opw-4108057 Forward-Port-Of: odoo/odoo#176608
Original PR description
In versions v17 and up, a div with class `.o-discuss-CallInvitations` was causing issues by blocking the scrollbar's up arrow, preventing users from scrolling up. To address this, the display of the `.o-discuss-CallInvitations` div is now conditional, based on `store.discuss.ringingThreads.length > 0`. This ensures the div only appears when necessary, avoiding obstruction of the scrollbar and improving usability. opw-4108057 Forward-Port-Of: odoo/odoo#176608