Daily updates from Odoo
Tuesday, January 20, 2026
374 changes
16 changes
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets in Odoo. These tests ensure the correct handling of hidden sections, pricing options, and product movements, enhancing the reliability and functionality of sales order management. The changes improve the overall stability and accuracy of these key features.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226613Enhancements to existing features
This update enhances the flexibility of Odoo's website builder by introducing a new system for modifying shape groups. Plugins can now directly adjust these groups, allowing for more dynamic and customizable website designs. This change improves the ability to tailor website layouts to specific business needs.
Original PR description
This commit defines `image_shape_groups_providers` and `background_shape_groups_providers` as new plugin resources. These resources return functions that receive the current shape groups, allowing plugins to mutate them directly or return groups to be merged into the final configuration. Forward-Port-Of: odoo/odoo#243121
Resolved issues and error corrections
A recent change in the Odoo POS system was causing users to be blocked from printing, leading to frustration. This pull request reverts a previous update to restore the normal printing functionality and resolve this blocking issue.
Original PR description
Since preparation printers are ignoring the print job requests sent a lot of users are being blocked in pos UI. This reverts commit 5e290c264f14108e036344663fc459bf77da265e. This unblocks the user's UI in case of a duplicate print Forward-Port-Of: odoo/enterprise#104421
This update fixes a potential issue in the Turkish accounting module (l10n_tr_nilvera) by correcting the default journal type used when fetching documents. Previously, the default was set incorrectly, which could lead to errors. The change now sets the default to 'purchase' to ensure proper accounting practices and prevent misuse.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update resolves a technical issue preventing the Odoo IoT box from starting correctly. The addition of a required dependency, geoip2, was necessary for the Odoo application to function on the IoT environment. This ensures stable operation of the Odoo instance on the IoT box.
Original PR description
This PR adds geoip2 to packages required by the iot box in saas-19.2 Without geoip2 odoo doesn't start on the iot box Backport of https://github.com/odoo/odoo/pull/243751 to allow to use saas-19.1 images with dbs in master
This update ensures the Apps application accurately displays the number of industry modules categorized by type. Previously, the count was always shown as zero due to a change in the underlying data source. This change corrects the display to provide a more precise count for users.
Original PR description
Before this commit, the count of industry modules by category in Apps application was always 0. With the change of API of apps.odoo.com, there is a possibility to display the exact count by category. In this aim, this commit adds the version to the route arguments such that the count is correctly displayed. task-5222706 Forward-Port-Of: odoo/odoo#243482
This update corrects a bug that occurred when users attempted to change a tax lock date to a date in the past. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves the stability and reliability of financial reports.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the BR Point of Sale module. The change ensures the module aligns with recent legal requirements and automatically installed features. The fix prioritizes accurate reporting for Brazilian businesses.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update reverts a recent change that added new features to the mobile dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Adaptations were made to ensure existing features like the carousel and granularity selector continue to function correctly.
Original PR description
### [REV] spreadsheet_dashboard: go back to chart-only mobile dashboard This commit reverts 5cde5114d971a9edc12c9708ae0ea86bfb6db3b2, so the mobile dashboards go back to showing only the figures. Some adaptations were necessary to make the new features (carousel, granularity selector, ...) work. Task: [5447027](https://www.odoo.com/web#id=5447027&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242288
A recent issue prevented users from successfully obfuscating their databases using the Odoo command-line interface. This update corrects a problem where the command incorrectly processed database names, causing an error. The fix ensures the obfuscate command functions as intended, allowing users to securely protect their data.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280 Forward-Port-Of: odoo/odoo#244577
This update prevents the HTML Builder editor from freezing due to rare errors. A timeout mechanism is now in place to release the editor and alert the user to potential data issues during saving. This enhances the user experience and prevents data loss.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911 Forward-Port-Of: odoo/odoo#233079
This update resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The fix applies a standard image scaling method (object-fit: cover) to ensure avatars display correctly and consistently across all user profiles. This improves the overall user experience and visual presentation.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243434 Forward-Port-Of: odoo/odoo#242320
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate financial reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243941 Forward-Port-Of: odoo/odoo#238428
This update resolves an issue where certain carriers weren't correctly integrated with shipping partners within the website sale module. The change ensures that carrier options align properly with available shipping partners, leading to more accurate shipping calculations and a smoother customer experience. This improves the reliability of the online ordering process.
Original PR description
Forward-Port-Of: odoo/odoo#244649 Forward-Port-Of: odoo/odoo#244035
This update fixes an error in the financial reporting for Vietnam (l10n_vn_reports) that resulted in inaccurate calculations for key balance sheet codes (420.1 and 420.2). The changes ensure these figures accurately reflect equity and profit, improving the reliability of financial statements.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104786 Forward-Port-Of: odoo/enterprise#104373
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain clear and adhere to API specifications, improving the accuracy of VAT processing for Vietnamese businesses.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
7 changes
Resolved issues and error corrections
This update resolves a problem where GS1 barcodes were causing errors during scanning, preventing products from being correctly identified. The fix allows the system to handle GS1 barcodes without interruption, ensuring accurate product and location detection within the Odoo Enterprise system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
This update corrects a bug that occurred when attempting to change a tax lock date to a past date. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves the stability and reliability of financial reports.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
A recent update introduced a bug in the delivery module, causing incorrect calculations. This pull request reverts the problematic change to restore the original, correct behavior. The issue will be addressed in a future update.
Original PR description
Bug introdcued in: https://github.com/odoo/odoo/commit/6901863d30f524c160971c9f5c97846ffd1fa5f5 The fix was misleading because forcing the context in the unit test caused incorrect assumptions. Passing `default_carrier_id` in the context prevents the computed method from being called, breaking expected behavior. This revert restores the previous behavior as the fix is incorrect. The issue will be resolved in another PR.
This update resolves an issue preventing refunds for NFC-e transactions in Point of Sale. Previously, a technical error caused a 'not found' message when attempting to process refunds. The fix ensures the system correctly identifies and uses the necessary invoice information for refund processing, improving the reliability of NFC-e transactions.
Original PR description
**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice
**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.
We now check if there is a value in res['invoice_refs'] and if not we set it.
opw-5359407This update fixes a potential issue where payroll calculations in the US could incorrectly show employees owing money to the state. The change ensures that taxable income defaults to zero when state deductions exceed gross income, preventing negative values on payslips and ensuring accurate tax reporting.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#102599 Forward-Port-Of: odoo/enterprise#98114
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring accurate price difference calculations and preventing erroneous invoices.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243801 Forward-Port-Of: odoo/odoo#238428
This update fixes an error in the financial reporting for Vietnam (l10n_vn_reports) that resulted in inaccurate calculations for key balance sheet codes (420.1 and 420.2). The changes ensure these figures accurately reflect equity and profit distributions, improving the reliability of financial reports.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104786 Forward-Port-Of: odoo/enterprise#104373
7 changes
Enhancements to existing features
This update enhances the testing process for paying invoices using bank statement data. A new test helper has been introduced to streamline and standardize these tests, ensuring more reliable invoice payment processing within the Odoo system. This improves the overall stability and accuracy of invoice payments.
Original PR description
Forward-Port-Of: odoo/odoo#244281
Resolved issues and error corrections
This update fixes a bug that occurred when users tried to change a tax lock date to a past date. The change prevents the system from generating incorrect default values for reports, ensuring accurate financial reporting. This resolves a potential error that could have impacted data accuracy.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update resolves an issue where Time-Off Responsibles lacked the necessary permissions to refuse approved leave requests. The fix ensures they can properly manage leave by correctly handling access rights during the refusal process, preventing access errors.
Original PR description
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This…
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it. https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901 According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees. Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink. **Solution:** This fix checks wether the user has write access to the related hr.leave record, then uses sudo(). The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations. This is in a similar fashion as the behavior for approving the leaves. ****Steps to Reproduce:**** - Create a Leave Type that requires validation from a manager, and assign one to an employee. - Remove any access rights to Time-Off for the user, but leave Time off Responsible checked. - Assign the user as time-off responsible for the employee - Log in as the user and approve the leave - When refusing the leave, you should get an access error. opw-5178783 Forward-Port-Of: odoo/odoo#238205
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243801 Forward-Port-Of: odoo/odoo#238428
This update fixes a critical issue where the Moroccan tax report XML export incorrectly reflected all bills in a period, ignoring the default cash basis accounting. The fix uses a new SQL query to accurately calculate taxes, ensuring consistent and reliable data in the export. This improves data accuracy and efficiency.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file. Forward-Port-Of: odoo/enterprise#104619
This update corrects a bug where the 'Import Bank Statement' action incorrectly selected a journal in multi-company environments due to elevated server permissions. The fix ensures the action now filters by the currently chosen company, preventing incorrect journal selection and improving data accuracy. A new test confirms the fix's reliability.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain clear and adhere to API specifications, improving the accuracy of VAT processing for Vietnamese businesses.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
6 changes
Resolved issues and error corrections
This update fixes an issue where the website's cookie consent settings weren't being saved after changing the 'I agree' button style to the default. The change ensures that user consent is properly recorded when the Cookie Bar is updated, maintaining data integrity and compliance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a situation where users in different branches could create the same tax name. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee each tax name is unique, avoiding potential errors and data inconsistencies, especially in larger organizations with multiple branches.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix addressed a missing size definition, allowing the map to render. However, the map remains non-interactive, indicating a separate problem that needs attention.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104114
This update resolves a problem where GS1 barcodes were causing errors during scanning, preventing products from being correctly identified. The fix allows the system to handle GS1 barcodes without interruption, ensuring accurate product and location detection within the Odoo system. This improves the reliability of the barcode scanning functionality.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from attempting to generate default external values when the lock date is in the past, ensuring smoother operation and preventing unexpected errors.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
Features or functions removed from Odoo
This update removes a no-longer-used folder within the Odoo Enterprise software. This cleanup improves the overall organization of the codebase and reduces potential confusion for developers. The change is a routine maintenance task to ensure efficient development.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167
10 changes
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets within Odoo. These tests ensure the correct handling of hidden sections, duplicate creation, and quantity adjustments when products are moved between optional sections, improving product configuration and order management.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226613Resolved issues and error corrections
This update fixes an issue where loyalty points weren't accurately adjusted when a customer reduced the quantity of a free, loyalty-rewarded product. Previously, decreasing the order quantity didn't correctly reflect the remaining points owed. Now, the system recalculates loyalty programs to ensure points are updated accurately after quantity changes, improving the accuracy of customer rewards.
Original PR description
When decreasing the quantity of a product that was awarded for free using loyalty points, the points spent were not updated accordingly. Steps to reproduce: ------------------- * Create a loyalty program that grant 1 free product A for 1 point * Create a loyalty card with 3 points for partner A * Open PoS and make an order for partner A * Just claim the 3 free products A using loyalty points * Decrease the quantity of product A from 3 to 2 > Observation: The points spent were not updated accordingly. It should be 3 - 2 = 1. Why the fix: ------------ We need to recompute the loyalty programs when the quantity of a reward is changed. This was not done if the changes happened in `_updateRewardLines`. We now track if changes happened in this method and we call `orderUpdateLoyaltyPrograms` if needed. opw-5177593 Forward-Port-Of: odoo/odoo#244082 Forward-Port-Of: odoo/odoo#242816
This update corrects a technical issue preventing access to certain payroll features for specific user groups. The change adds group permission controls within the HR employee configuration, ensuring proper access rights are enforced. This resolves a test failure and improves the stability of the payroll system.
Original PR description
The test_employee_fields_groups unit test from hr/tests/test_self_user_access.py was not successful on the runbot due to access restriction. I added the groups parameters to the l10n_sa_gosi_api_is_available field definition in the hr_employee extension from the l10n_sa_hr_payroll_gosi module. Runbot error: 233954 Forward-Port-Of: odoo/enterprise#104883
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from generating default external values when the lock date is set in the past, ensuring smoother operation and preventing unexpected errors.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update fixes a previous issue where the Apps application incorrectly showed zero industry module counts. By adding version information to the route arguments, the system now accurately displays the exact number of modules by category, aligning with changes in the apps.odoo.com API.
Original PR description
Before this commit, the count of industry modules by category in Apps application was always 0. With the change of API of apps.odoo.com, there is a possibility to display the exact count by category. In this aim, this commit adds the version to the route arguments such that the count is correctly displayed. task-5222706 Forward-Port-Of: odoo/odoo#243482
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the Point of Sale module. The change was identified late due to legal requirements and automatic installation. The fix moves the necessary logic to the correct module for proper functionality and ensures compliance with the latest regulations.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update resolves an issue where user avatars in the Chat UI were appearing distorted or incorrectly sized. The change ensures avatars are displayed correctly using the 'object-fit: cover' style, providing a consistent and professional user experience. This improves the visual quality of user profiles.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243434 Forward-Port-Of: odoo/odoo#242320
This update reverts a recent change that introduced new features to the mobile dashboards. It now returns the dashboards to display only charts, simplifying the user experience. Some adjustments were made to ensure existing features like the carousel and granularity selector continue to function correctly.
Original PR description
### [REV] spreadsheet_dashboard: go back to chart-only mobile dashboard This commit reverts 5cde5114d971a9edc12c9708ae0ea86bfb6db3b2, so the mobile dashboards go back to showing only the figures. Some adaptations were necessary to make the new features (carousel, granularity selector, ...) work. Task: [5447027](https://www.odoo.com/web#id=5447027&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242288
This update optimizes the calculation of product costs within Odoo, specifically addressing a performance bottleneck in the inventory module. By separating the cost calculation logic, the system now avoids unnecessary database queries, resulting in significantly faster loading times for common inventory views. This improves overall system responsiveness.
Original PR description
Issue: With the recent changes for valuation, multiple product valuation fields are computed via one compute method _compute_value. One such field is avg_cost, which will always call the…
Issue: With the recent changes for valuation, multiple product valuation fields are computed via one compute method _compute_value. One such field is avg_cost, which will always call the _get_standard_price_at_date method under all circumstances. _get_standard_price_at_date results in additional queries being run, which become costly en-mass in the case of many products being read. This results in unnecessary overhead for workflows which only read one of the other fields in the compute, such as total_value. For instance, when accessing the locations list view in the inventory application, roughly 2/3 of the execution time is spent running queries to calculate avg_cost even though the field is not being read. Solution: A new compute method _compute_avg_cost must be made, which simply separates the avg_cost logic from the multi-field _compute_value method. This way, additional queries resulting from _get_standard_price_at_date are avoided for workflows which do not require such information. Benchmark: Loading the inventory > locations list view for a DB with several thousand locations and products: | Before | After | |----------|---------| | 2.9 sec | 0.9 sec | opw-5224646
This update fixes an issue where product names on invoices were being incorrectly concatenated, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain separate and adhere to API specifications, improving invoice clarity and compliance.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
13 changes
Enhancements to existing features
This update streamlines the process for managing product pricing tags. The 'update all' button has been removed, and now only the update button for edited products is available. This simplifies the user experience and reduces the potential for errors when updating pricing.
Original PR description
To ease update of pricer tags, we removed the "update all" button to only have the one that update edited products. Task: 5380332
Resolved issues and error corrections
This update removes a redundant 'OK' button from form dialogs within the Point of Sale (POS) system. Previously, this button was only removed when the 'pos_appointment' module was installed. Now, the change is applied consistently across all POS form dialogs, creating a more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165
This update fixes an error in the Point of Sale order report that incorrectly calculated margins for refunded orders. The fix ensures that refunds are properly accounted for, displaying accurate margins based on order value, improving reporting accuracy for financial analysis.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change was only applied when a specific module was installed. Now, the change is consistent across all POS form dialogs, providing a cleaner and more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197
This update fixes an issue where overtime calculations were inaccurate when employees were on leave. Now, if an employee works on a day they are off, all hours worked are treated as overtime, excluding breaks. This ensures accurate overtime payments for all employees.
Original PR description
This PR aims to fix how the overtime is being calculated with quantity based rules : - The expected _hours didn't take into account the leaves of the day , so if the user was on a leave, it would considered him absent ( give him negative overtime) , because he has no attendances that day. - if the employee took a whole day off, and decided to work on it, all the hours should be considered as overtime, the brake shouldn't be included (ex : his normal work sched is morning (9h-12h) , break(12h-13h), afternoon(13-17h) , he's already getting paid for that time , so every single hour worked that day from 12am to 12 pm is added time , and there is no break in added time) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where a default rate was incorrectly overriding the rate specified during testing for the FedEx delivery module. By clearing these outdated rates in the test environment, we ensure accurate rate calculations and prevent potential discrepancies in delivery cost reporting. This improves the reliability of our testing process.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965
This update fixes tests related to overtime calculations based on quantity. The changes reflect a recent update to how overtime is calculated, ensuring the tests accurately reflect the new logic. This improves the reliability of our overtime tracking system.
Original PR description
this PR made some changes to how overtime is calculated by quantity based rules. This PR aims to adapt the test to the new calculation logic
This update resolves a bug where the link popover would incorrectly appear on input fields within protected nodes. The fix ensures the popover only displays when an editable element is focused, improving the user experience and preventing unexpected behavior when renaming files within the HTML editor.
Original PR description
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span protected non-editable><input></span>` If the selection is inside the link and the link preview popover is visible, clicking on the input triggers a selection change. Since the input is inside a protected node, the editor keeps the previous editable selection. As a result, `LinkPlugin.handleSelectionChange` still treats the selection as being inside the link and reopens the link popover. Solution: Only show the link popover when the `activeElement` is the editable element. Steps to reproduce: - Add a link. - Upload a file. - Place the selection on the link. - Focus the file name input to rename it. - Observe that the link popover is shown on the file name input. opw-5414078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a calculation error in the fleet module related to the initial acquisition date of vehicles. By setting a default acquisition date, the system now accurately calculates baseline ATN (Asset Tracking Net) values, leading to more precise reporting and financial analysis. This ensures better tracking of vehicle depreciation and asset management.
This update resolves an issue where government entities using TAN-based GSTINs were incorrectly flagged with validation errors when creating contacts in Odoo. The change adjusts the validation process to correctly handle TAN-based GSTINs, ensuring proper partner creation for these important customers. This improves data accuracy and usability.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356
This update corrects a visual glitch where an 'Add Item' button incorrectly appeared on web page snippets after all topics were removed. The fix ensures the button disappears when no topics are present, improving the user experience and preventing unexpected errors. This change impacts multiple snippet types.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244034
This update corrects a bug where the partner ID wasn't consistently passed through the stock move creation process, specifically in multi-step delivery scenarios. The change ensures that the correct customer or supplier is associated with stock moves, resolving issues with order fulfillment. This impacts sales and purchase order processing.
Original PR description
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock ### Issue: The partner_id (contact field) of stock move is no longer propagated in pull chain since the…
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock
### Issue:
The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a
#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.
### Cause of the issue:
Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.
### Additional changes:
1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381
2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.
3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346
4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23
5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11
opw-5428063
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a potential issue where users could create duplicate tax names in different branches of Odoo. Previously, the system only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee each tax name is unique, preventing conflicts and ensuring data accuracy across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
8 changes
Enhancements to existing features
This update optimizes how Odoo generates reports by grouping related domain searches. Previously, each report filter required a separate database query, leading to slow performance. This change combines multiple queries, significantly speeding up report generation times – specifically reducing the time to open the Generic Balance Sheet from 1 minute 35 seconds to 36 seconds.
Original PR description
Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725
Resolved issues and error corrections
This update resolves an error that prevented non-employee users from creating expenses from documents. The issue stemmed from a required field ('employee_id') being unintentionally set to 'false' when no employee was linked to the user. The fix now displays a user-friendly error message instead of crashing the system.
Original PR description
Currently an exception is generated when the non-employee user tries
to generate expenses from the documents.
Steps to produce an error:
- Install the `documents_hr_expense` module without demo data
- Delete employee `Administrator`
- Upload any PDF/image file inside the company's `Internal` folder
- Click on the uploaded document and click on the `Create an Expense` button
Error: `ValueError: NotNullViolation('null value in column "employee_id" of ...`
This error occurs because `employee_id` is required when creating an
expense. Since the current user is not linked to an employee record,
`employee_id is` set to false, which causes the issue.
This commit resolves the issue by raising a `UserError` when the current
user is not linked to an employee.
sentry-7192984733This update fixes a RecursionError that occurred when producing large quantities of products tracked with serial numbers. The issue stemmed from a process that repeatedly updated deadlines across multiple manufacturing steps, exceeding Python's recursion limit. This change ensures stable production for high-volume serial-tracked orders.
Original PR description
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Produce the 100 units on the child MO of product C (100 backorders are created). - On the main MO (product A), click on "Prepare MO". - Attempt to produce product B. → RecursionError: maximum recursion depth exceeded. **Cause** While setting `move_finished_ids`: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806 the `deadline_date` of the final move is updated: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63 This deadline is then propagated to chained moves: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55 via: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61 This propagation retriggers the `move_finished_ids` setter recursively on other moves. The recursion depth grows with the number of generated moves, eventually exceeding Python's maximum recursion limit. opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)
This update resolves an issue where accessing settings in the Romanian language version of Odoo resulted in an error. The fix corrects a mismatch in text references within the Odoo codebase, ensuring the settings app functions correctly when the Romanian language is selected. This improves usability for Romanian-speaking users.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346
This update corrects an error in the Chilean invoicing process. The system previously failed when a document number contained non-numeric characters. A new constraint has been added to ensure document numbers are purely numeric, aligning with Chilean regulations and preventing invoice processing issues. This ensures accurate and compliant invoice generation.
Original PR description
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits. Steps to replicate: - Install…
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.
Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.
Error:
```
File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
res = super().action_post()
File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
self._post(soft=False)
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
move._l10n_cl_create_dte()
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```
Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.
Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.
Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.
[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where FedEx labels incorrectly displayed addresses containing special characters (like accents or non-English characters). The change ensures all addresses are converted to ASCII characters, resulting in accurate and consistent label formatting for FedEx shipments. This prevents misinterpretations and ensures proper label printing.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724
This update resolves an issue where the 'Month 13' column in the Mexican l10n_mx Trial Balance report incorrectly displayed numbers. The fix removed a redundant 'balance' column, ensuring accurate reporting of financial data. This improves the reliability of financial reports for Mexican businesses using Odoo Enterprise.
Original PR description
With l10n_mx company: 1 - Add the balance column to the “Trial Balance” accounting report 2 - Create a journal entry for the date 12/31/2024 for 5000 as a credit on the account 119.01.01 VAT due and balance it with 5000 as a debit on another account 3 - Open the Trial Balance report and click on the “Month 13” filter as well as the year 2024. Notice that the “Month 13” column has some numbers when there should not be a number in that column. Delete the balance column from the “Trial Balance” accounting report and notice that the numbers now appear in their appropriate columns. In the _l10n_mx_set_options_month_13 the way to find the initial value, month 13 and end value columns was hardcoded. opw-5222117 Forward-Port-Of: odoo/enterprise#104105
This update fixes a potential issue with the Odoo file upload service. Previously, the service struggled to handle different response types from Odoo controllers (JSON, JSONRPC, or HTML), leading to errors. Now, the service is more robust and handles a wider range of error responses, ensuring smoother file uploads.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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
7 changes
Resolved issues and error corrections
This update corrects a technical detail related to the translation of Odoo's Greek language support. The team identified and fixed an incorrect language code (`gr`) used in several modules, ensuring accurate translations for Greek-speaking users. This ensures proper localization and a better user experience for our Greek-speaking customers.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where newly added modules to the Odoo Enterprise system were not automatically included in the translation process. Adding these modules to the `.weblate.json` file ensures they will be properly translated, improving the quality and availability of the software for all users. This prevents modules from appearing untranslated.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable.
This update resolves an issue preventing non-admin website editors from saving images they upload from Unsplash. The fix ensures editors with appropriate permissions can successfully save changes to website content, improving the usability of the website editor feature. It addresses a security concern related to user access rights.
Original PR description
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in…
Scenario: - Setup Unsplash and install website - Set a user as "Website: Editor and Designer" - Login as that user and go to any website page with a qweb view - Go to edit mode and drop Text-Image in a view - Replace the image with an unsplash image and then save Result: the save fails without any message shown, and there is a security access WARNING in the logs. Note: a similar scenario can be done for a restricted editor that is editing a HTML field it has write access to. Issue: to save a model with res_id 0, we need to either be admin (base.group_system) or the record creator. Since 9c9c58a5a10101532cbf046d21d4a63c2b7d2838 to bypass the mimetype neutering of happening, we create the attachment as SUPERUSER. Then when we modify the attachment url (for unsplash images), we have no access right to the attachment since we are not the creator. Fix: create the attachment with the current user, and only use SUPERUSER to set the mimetype if it was neutered (ie. the user doesn't have write access right to ir.ui.view, which in normal use case should only happen for "Restricted Editor"). This way the image is created by the user that uploaded it and not SUPERUSER. opw-4850611 opw-5387258 opw-5489219
This update fixes a reporting issue related to salary certificates for employees in Switzerland. The ‘Period until’ and ‘Period from’ dates for salary certificate generation are now dynamically pulled from the employee’s data, ensuring accurate and up-to-date reporting requirements. This change simplifies the process for HR and finance teams.
Original PR description
make Period until and from dynamic from data
This update corrects a typo in the tests for Odoo's search highlight feature. This ensures the search functionality is working correctly and reliably for users. The fix prevents potential issues with search results.
Original PR description
Intoduced by https://github.com/odoo/odoo/pull/118794
A recent test for the HR Contract Reports module was unreliable due to a timing issue during chart animations. This fix ensures the chart is fully rendered before test clicks are triggered, making the test consistently pass and improving overall system stability. This resolves a flaky test that could potentially impact report generation.
Original PR description
The test *“click on HrContractEmployeeReportGraphView opens 'hr.contract' list view”* was flaky due to a race condition between the Chart.js entry animation and the simulated click. The test was clicking on bar coordinates computed from the final chart state while the initial animation was still running, causing the click handler to miss the target element. Adding `await nextTick()` ensures the graph is fully rendered before the click is triggered, making the test reliable. runbot-75191
This update fixes a security vulnerability in Odoo 17.0 where users could access Verifactu certificates for all companies, regardless of their permissions. The change restricts access to certificates based on company affiliation, ensuring data security and compliance. This prevents unauthorized access to sensitive business documents.
Original PR description
**PROBLEM** In 17.0, you can access the verifactu certificate of all companies. **STEP TO REPRODUCE** - Have 2 companies. - Create a certificate for each of them. - Setup Marc Demo with the Accountant role for the invoicing/accounting app. - Remove him from the ES company. - When accessing the verifactu certificate view, he will still have access to the ES company certificate. opw-5354383