Friday, February 14, 2025
26 changes · saas-17.4
Resolved issues and error corrections
Receipts and internal transfers created in the Barcode app now correctly keep the product's picking description on inventory lines. This helps warehouse and inventory users see the expected product instructions or notes consistently across apps.
Original PR description
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/odoo/odoo/pull/193996/files opw-4406582
This fixes how Field Service project reports organize report data behind the scenes. It helps prevent report errors or ambiguous results when related data tables contain similarly named fields.
Original PR description
The project report query joins multiple tables and aggregates on some fields, everything else should be in the group by clause. The group by here is using the select alias but it is better to use the full column name including the table alias, in case one of the joined tables has a column with the same name as the alias.
Miscellaneous changes
Before this commit, the response from the request that obtains the TURN servers from twilio would fail silently. This commit fixes this issue by logging the status code and te content of the response in case of failure. Forward-Port-Of: odoo/odoo#197723 Forward-Port-Of: odoo/odoo#197628
Original PR description
Before this commit, the response from the request that obtains the TURN servers from twilio would fail silently. This commit fixes this issue by logging the status code and te content of the response in case of failure. Forward-Port-Of: odoo/odoo#197723 Forward-Port-Of: odoo/odoo#197628
This commit fix this UI problem: When you are on an account_move view, create a line and input multiple analytic distributions, the line height stay fixed, and it crop the distributions, making the line unreadable. This commit add a variable height on the analytic_distribution field. task-4213064 Forward-Port-Of: odoo/odoo#194489
Original PR description
This commit fix this UI problem: When you are on an account_move view, create a line and input multiple analytic distributions, the line height stay fixed, and it crop the distributions, making the line unreadable. This commit add a variable height on the analytic_distribution field. task-4213064 Forward-Port-Of: odoo/odoo#194489
**Issue 1:** All taxes of the Malta localization don't have a tag for the base repartition line for the invoice type, but have one for the refund type. **Issue 2:** The tags for the refund type are all positive. They should be negative. opw-4557777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197736
Original PR description
**Issue 1:** All taxes of the Malta localization don't have a tag for the base repartition line for the invoice type, but have one for the refund type. **Issue 2:** The tags for the refund type are all positive. They should be negative. opw-4557777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197736
Since 1 January 2025, the VAT rates in Slovakia have increased from 20% to 23% and from 10% to 19%. This commit adds the new taxes and updates the fiscal position accordingly. task-4502344 Forward-Port-Of: odoo/odoo#197035 Forward-Port-Of: odoo/odoo#194686
Original PR description
Since 1 January 2025, the VAT rates in Slovakia have increased from 20% to 23% and from 10% to 19%. This commit adds the new taxes and updates the fiscal position accordingly. task-4502344 Forward-Port-Of: odoo/odoo#197035 Forward-Port-Of: odoo/odoo#194686
Steps to reproduce ================== - Install account - Open an invoice - Click on the cog - Click on "Generate a Payment Link" - Open the browser devtools and add a delay in the network tab to simulate a slow network - Edit the amount - Click on the Copy button => The copied URL is not up to date and contains the previous amount Cause of the issue ================== The copy button is actually a field named `link` Changing the `amount` causes an onchange that updates the
Original PR description
Steps to reproduce ================== - Install account - Open an invoice - Click on the cog - Click on "Generate a Payment Link" - Open the browser devtools and add a delay in the network tab to simulate a slow network - Edit the amount - Click on the Copy button => The copied URL is not up to date and contains the previous amount Cause of the issue ================== The copy button is actually a field named `link` Changing the `amount` causes an onchange that updates the `link` value. When the button is clicked, the amount field is blurred, and this starts the onchange. The link is then immediately copied without waiting for the new value. Solution ======== There is no mechanism in the framework made for this purpose, but what we can do, is wait for the model mutex to be unlocked. The lock is held during the onchange, so it is guaranteed that the up to date link is copied. opw-4358629 Forward-Port-Of: odoo/odoo#197008
Forward-Port-Of: odoo/odoo#197397 Forward-Port-Of: odoo/odoo#197127
Original PR description
Forward-Port-Of: odoo/odoo#197397 Forward-Port-Of: odoo/odoo#197127
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197373
Original PR description
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197373
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behav
Original PR description
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behavior before PR: The domain is built inside the `_run_manufacture` method Desired behavior after PR is merged: The domain is built in a dedicated method that can be easily overwritten in custom modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196396 Forward-Port-Of: odoo/odoo#196156
Steps to Reproduce: - Create a batch transfer. - Print the batch transfer report. Problem: The unit of measure is not displayed next to the quantity. Solution: Access the unit of measure from group_uom in uom instead of move_operation. OPW-4476534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197382 Forward-Port-Of: odoo/odoo#196497
Original PR description
Steps to Reproduce: - Create a batch transfer. - Print the batch transfer report. Problem: The unit of measure is not displayed next to the quantity. Solution: Access the unit of measure from group_uom in uom instead of move_operation. OPW-4476534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197382 Forward-Port-Of: odoo/odoo#196497
When doing an export, a lot of information are computed depending on the partner, the company and the transaction. This commit will modify the field Invoice Type Transaction which is defined in a structure of 7-digit code: Standard Invoice must have 01 as the first 2 digits and 02 for simplified tax invoice. Other 5 digits depend on nature of the transaction. Before this commit we used to send for Individual contacts, 0200000 for all invoices, where the country of the Customer is not Sa
Original PR description
When doing an export, a lot of information are computed depending on the partner, the company and the transaction. This commit will modify the field Invoice Type Transaction which is defined in a structure of 7-digit code: Standard Invoice must have 01 as the first 2 digits and 02 for simplified tax invoice. Other 5 digits depend on nature of the transaction. Before this commit we used to send for Individual contacts, 0200000 for all invoices, where the country of the Customer is not Saudi Arabia. But it's actually wrong and we should send 0100100 which is a simple export invoice. To fix that issues we added a condition for an invoice to be simplified that the partner need to be an individual from Saudi Arabia. task-4504987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196976 Forward-Port-Of: odoo/odoo#195216
**Issue** When converting an invoice into a credit note, the fiscal position is lost while other fields are retained. Steps to Reproduce: 1. Go to Customer Invoices and create a new invoice. 2. Fill in all the necessary details, including the Fiscal Position. 3. Click on Switch into Invoice/Credit Note to convert the invoice into a credit note. 4. Observe that all data is transferred except for the Fiscal Position, which is missing. Expected behavior: The Fiscal Position should be r
Original PR description
**Issue** When converting an invoice into a credit note, the fiscal position is lost while other fields are retained. Steps to Reproduce: 1. Go to Customer Invoices and create a new invoice. 2. Fill…
**Issue** When converting an invoice into a credit note, the fiscal position is lost while other fields are retained. Steps to Reproduce: 1. Go to Customer Invoices and create a new invoice. 2. Fill in all the necessary details, including the Fiscal Position. 3. Click on Switch into Invoice/Credit Note to convert the invoice into a credit note. 4. Observe that all data is transferred except for the Fiscal Position, which is missing. Expected behavior: The Fiscal Position should be retained when converting an invoice to a credit note. Actual behavior: all data is transferred except for the Fiscal Position, which is lost. **Root Cause** The issue occurs in the action_switch_move_type method. When switching move_type, the method does not explicitly retain fiscal_position_id. Unlike static fields such as incoterm_id, the fiscal position is often recomputed dynamically. Writing changes to move_type likely triggers onchange methods that reset the fiscal position, leading to its removal. **Fix** Explicitly preserving fiscal_position_id when updating move_type prevents Odoo’s automatic recomputation from clearing the field. This ensures that fiscal positions are consistently retained, maintaining expected accounting behavior. opw-4497662 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196673
Before this commit, due to the group place on the setting, the cash basis option was not displayed to user with only invoicing. Now, we want the user (with only invoicing) to be able to see it but not modifying the account on the settings. It will allow the users to choose the tax exigibility on the taxes, which for french user is important since depending on that the sentence "Option to pay tax on debits" will be displayed on the invoice. task: 4342603 --- I confirm I have signe
Original PR description
Before this commit, due to the group place on the setting, the cash basis option was not displayed to user with only invoicing. Now, we want the user (with only invoicing) to be able to see it but not modifying the account on the settings. It will allow the users to choose the tax exigibility on the taxes, which for french user is important since depending on that the sentence "Option to pay tax on debits" will be displayed on the invoice. task: 4342603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195332 Forward-Port-Of: odoo/odoo#190995
… on company parts Forward-Port-Of: odoo/enterprise#79363
Original PR description
… on company parts Forward-Port-Of: odoo/enterprise#79363
This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#78901 Forward-Port-Of: odoo/enterprise#78014
Original PR description
This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#78901 Forward-Port-Of: odoo/enterprise#78014
In commit fb14e5793f924de21755a2b8e72ef9c651c9fb43, a way to handle related company fields was added, however this doesn't take into account the case where a model _inherits from another model, in that case the field is `inherited` and should be treated the same way as a stored field. Steps - Install Sales and Data Cleaning - Be in a multicompany database - Create a deduplication rule for the product variant model. - Add some field in the "Unique ID Field". - Deduplicate -> ** psycopg2.e
Original PR description
In commit fb14e5793f924de21755a2b8e72ef9c651c9fb43, a way to handle related company fields was added, however this doesn't take into account the case where a model _inherits from another model, in that case the field is `inherited` and should be treated the same way as a stored field. Steps - Install Sales and Data Cleaning - Be in a multicompany database - Create a deduplication rule for the product variant model. - Add some field in the "Unique ID Field". - Deduplicate -> ** psycopg2.errors.UndefinedColumn: column product_product__product_tmpl_id.product_tmpl_id does not exist ** opw-4368443 Forward-Port-Of: odoo/enterprise#79239 Forward-Port-Of: odoo/enterprise#75190
Add more info to the AR EDI XML file: new required tag CondicionIVAReceptorId where we inform the AFIP responsibility code of the partner. LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#78934
Original PR description
Add more info to the AR EDI XML file: new required tag CondicionIVAReceptorId where we inform the AFIP responsibility code of the partner. LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#78934
<setting id="avatax_settings" ...> is created by account, to be inherited by account_avatax. Use a unique id here to not break inheriting views in account_avatax. This uses a slightly awkward id because the more logical "l10n_br_avatax_settings" id is already used below. This issue has remained unnoticed because the account_avatax module is usually installed first. As a result, its views have lower database IDs and are applied before others. However, if you install the l10n_br_avatax module f
Original PR description
<setting id="avatax_settings" ...> is created by account, to be inherited by account_avatax. Use a unique id here to not break inheriting views in account_avatax. This uses a slightly awkward id because the more logical "l10n_br_avatax_settings" id is already used below. This issue has remained unnoticed because the account_avatax module is usually installed first. As a result, its views have lower database IDs and are applied before others. However, if you install the l10n_br_avatax module first (e.g., in a Belgian database) and then install the account_avatax module later, the l10n_br_avatax settings view will take precedence. This causes the Avatax settings to display incorrectly. opw-4547721 Forward-Port-Of: odoo/enterprise#78894
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
Original PR description
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications. This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries. See community PR for more details. Task-4559249 Forward-Port-Of: odoo/e
Original PR description
Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications. This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries. See community PR for more details. Task-4559249 Forward-Port-Of: odoo/enterprise#79132 Forward-Port-Of: odoo/enterprise#79048
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module T
Original PR description
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module This will trigger the constraint: ``` psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "whatsapp_template_unique_name_account_template" DETAIL: Key (template_name, lang_code, wa_account_id)=(invoice, en, 1) already exists. ``` Forward-Port-Of: odoo/enterprise#78501
## What was done? This pull request includes a change to the `payment_sepa_direct_debit/models/payment_transaction.py` file to correctly extract the last 4 digits of the IBAN number associated with a SEPA direct debit mandate. Key change: - Modified the `_sdd_notify_debit` method to compute the `iban_last_4` by replacing spaces in the account number and extracting the last 4 digits, instead of using the first 4 digits of `payment_details`.Switched to using the last 4 digits of the account
Original PR description
## What was done? This pull request includes a change to the `payment_sepa_direct_debit/models/payment_transaction.py` file to correctly extract the last 4 digits of the IBAN number associated with a…
## What was done? This pull request includes a change to the `payment_sepa_direct_debit/models/payment_transaction.py` file to correctly extract the last 4 digits of the IBAN number associated with a SEPA direct debit mandate. Key change: - Modified the `_sdd_notify_debit` method to compute the `iban_last_4` by replacing spaces in the account number and extracting the last 4 digits, instead of using the first 4 digits of `payment_details`.Switched to using the last 4 digits of the account number from the mandate instead of just the first 4 characters from payment details. This improves accuracy in displaying IBAN info. ## Why this change? The existing implementation is incorrect and fails to adhere to EU regulations regarding SEPA Direct Debit (SDD). According to these laws, the payment notification must display the **last** four digits of the account number from which the payment is collected. However, the current system erroneously shows the first four digits, and in some instances, it even displays an incorrect number. This revision guarantees that the account number displayed is derived from the authorized mandate, which is the sole permissible source. Forward-Port-Of: odoo/enterprise#78792
Forward-Port-Of: odoo/enterprise#79208
Original PR description
Forward-Port-Of: odoo/enterprise#79208
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79232 Forward-Port-Of: odoo/enterprise#77398
Original PR description
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79232 Forward-Port-Of: odoo/enterprise#77398
Steps to reproduce ============= 1. Allow edit access to portal user. 2. Try to publish an article from the portal user. The portal user has no right to publish/unpublish articles. After this commit ============== This commit prevents access error when portal users try to publish an article. Task-4414401 Forward-Port-Of: odoo/enterprise#76350
Original PR description
Steps to reproduce ============= 1. Allow edit access to portal user. 2. Try to publish an article from the portal user. The portal user has no right to publish/unpublish articles. After this commit ============== This commit prevents access error when portal users try to publish an article. Task-4414401 Forward-Port-Of: odoo/enterprise#76350