Monday, January 12, 2026
22 changes · saas-18.3
Resolved issues and error corrections
This update fixes a visual issue where long product names in the combo configurator popup caused misalignment of product cards. The change ensures all product cards maintain consistent alignment and dimensions, regardless of name length, providing a cleaner and more professional user experience.
Original PR description
Before this commit: ================= Product cards with long names caused a slight vertical misalignment in the combo configurator popup, resulting in inconsistent card sizes within the grid. After this commit: ================== Ensure all product cards remain uniformly aligned and maintain consistent dimensions in the combo configurator popup, even when product names are long. Task:5447320 Forward-Port-Of: odoo/odoo#241720
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures compliance with Luxembourg tax regulations and accurate reporting to tax authorities, resolving a potential data discrepancy.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update corrects a problem with Odoo invoices generated for Danish customers (l10n_dk). The issue stemmed from using the incorrect codelist for the EndpointID, preventing the invoices from passing validation checks. This ensures invoices comply with Danish regulations and can be successfully processed.
Original PR description
**PROBLEM** Generated OIOUBL files don't pass schematrons validations. **STEP TO REPRODUCE** 1. Install the l10n_dk module. 2. Create a dk partner with an adress, and VAT number (DK12345674 for example, don't forget to add a street number for the DK Company address). 3. Create an invoice for the DK partner, and download the xml. 4. Use this validator https://oioubl.nemhandel.dk/validation (Odoo Peppol IAP validator tests oioubl version 3.0 which is not the version we want to test). **CAUSE** We used [wrong codelist](https://oioubl-demo.nemhandel.dk/oioubl/kodelister/ElectronicAddressSchemeCode-3.0.html) (oiubl3.0) for schemeID instead of the [one we should use](https://oioubl21.oioubl.dk/Codelists/en/urn_oioubl_scheme_endpointid-1.1.html) (oioubl2.1). opw-5379474 Forward-Port-Of: odoo/odoo#240586
This update corrects a discrepancy in the calculation of employment bonuses for the Belgian payroll module (l10n_be_hr_payroll). The changes ensure bonus calculations are accurate up to March 2026, aligning with the latest tax regulations. This update maintains accurate payroll reporting for our Belgian clients.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures that the deduction amount is accurately reflected up to the year 2026, aligning with updated Belgian tax regulations. This ensures accurate payroll reporting and compliance for users in Belgium.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
This update corrects a technical issue where bank statements were incorrectly accessing elevated permissions. The change removes this unnecessary access, improving security and stability within the account module. This ensures data integrity and prevents potential vulnerabilities.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242899 Forward-Port-Of: odoo/odoo#242771
This update prevents users from creating new POS sessions when multiple online payment methods are linked to a single POS configuration. Previously, inconsistencies required manually deleting payment methods, leading to a frustrating user experience. Now, a constraint ensures only one online payment method is active per POS config, improving session stability.
Original PR description
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are…
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session. In addition, if a session is already open, it is no longer possible to resolve the situation: * From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method. * From `pos.config`: the payment methods field is read-only when there is an open session. We had to delete one of the online payment methods from the database directly to be able to open the POS session again. To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method. Forward-Port-Of: odoo/odoo#240343
This update ensures that leave dates automatically recalculate when an employee's or contract's working schedule changes. Previously, leave calendars weren't updated, leading to potential inaccuracies. This fix maintains accurate leave balances by reflecting the latest schedule.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242381 Forward-Port-Of: odoo/odoo#241284
This update fixes a minor issue in the HTML editor's testing process. The change ensures that test actions are executed correctly, preventing redundant selections and improving the reliability of hoot tests. This enhances the overall stability of the HTML editor module.
Original PR description
The `simulateArrowKeyPress` method used in hoot tests performs both an actual `press` and modifies the selection. However, in some cases, the `press` already updates the selection because of our own listeners, which leads to a selection similar to performing the action twice. This commit avoids this by making sure the default `press` did not get prevented by our own custom listeners before modifying the selection. task-5438683 Forward-Port-Of: odoo/odoo#241604
This update fixes a technical issue that caused users to receive confusing tracebacks when errors occurred during ZATCA onboarding. Now, users will see a clear, user-friendly alert message with the actual error returned by ZATCA, improving the onboarding experience and ensuring compliance.
Original PR description
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace…
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace result in exactly 127 bytes; see refs [1] and [2])—the system returns a traceback to the user instead of a clear and user-friendly error message. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType' This is due to the check-in `_l10n_sa_request_production_csid` for an 'error' key, not present in the response when an OTP is invalid because in these cases, the `_l10n_sa_call_api` returns the response_data directly. This fix improves the behaviour by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback. This ensures a better experience and compliance with CCSID onboarding flows. [1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571 [2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960 sentry-7169834710 Forward-Port-Of: odoo/odoo#242810
This update corrects a problem in the Barcode app for Manufacturing Orders. When tracking is disabled, a manufacturing order creation process incorrectly deleted stock move lines, preventing components from being added. The fix ensures the necessary data is available before the creation process, resolving this issue and improving order accuracy.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws…
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163 Forward-Port-Of: odoo/enterprise#103619 Forward-Port-Of: odoo/enterprise#98440
This update fixes an error in how stock valuations are calculated when processing foreign currency purchases with auto-standard products. Previously, incorrect currency exchange rate adjustments were being applied, leading to inaccurate inventory values. The fix ensures that stock valuations accurately reflect the product cost in the correct currency.
Original PR description
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the…
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since [1], in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. [1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7 OPW-5380665 Forward-Port-Of: odoo/odoo#243094 Forward-Port-Of: odoo/odoo#243029
This update enhances the customer display popup in Point of Sale, making it easier to access customer information on both desktop and mobile devices. Previously, the popup opened in a separate window, creating a usability challenge. Now, users can quickly scan QR codes or open the customer display directly on their device.
Original PR description
Changed to open the QR code popup on the desktop as well. Before it was opening directly in a new window and it was hard to open it on a separate device. The QR popup will: - on desktop: will show a button to open the customer display on the same device, or to scan the qr - on mobile: will show only the qr code to scan task-5129241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the 'Next Milestone' displayed in the Project list view was missing the deadline date. The fix ensures that milestone names now accurately include the deadline, providing clearer visibility for project timelines. This improves the accuracy of project planning and reporting.
Original PR description
**Steps to Reproduce:** - Install the Sale Project module. - Navigate to the Project module. - Enable Project Stages. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The context overridden in sale project did not pass the required context, cause the display_name computation did not add deadline to the display name. **Fix:** Passed the appropriate context in the action context to ensure the display name is correctly computed and displayed with its deadline. Task: 5255295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243189 Forward-Port-Of: odoo/odoo#241853
This update fixes a display issue in the Industry FSM module where milestone names weren't showing their associated deadlines. The fix ensures that milestone names now accurately include the deadline date, providing users with clearer project timelines within the Project Configuration section.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the action, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295 Forward-Port-Of: odoo/enterprise#103895 Forward-Port-Of: odoo/enterprise#103160
This update resolves a minor issue that caused tests for embedded actions to sometimes fail unpredictably. By adding a necessary wait for the user interface to update, we've made the tests more reliable and consistent. This ensures our software continues to function as expected.
Original PR description
In this commit, we add a missing await for an animation frame in an embedded action test. This ensures that the test waits for the DOM to update properly before proceeding, preventing potential flakiness in the test execution. runbot error~237752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243240
This update resolves a technical error that prevented users from successfully creating and saving bank statements within the Bank Journal Transactions feature. The issue stemmed from an undefined data source within the application, now corrected by utilizing props for data access. This ensures a smoother and more reliable experience for users.
Original PR description
We get an owl error: `TypeError: Cannot read properties of undefined (reading 'root').` The code tries to read data from this.env.model, but it is undefined. Steps To Reproduce: 1. Install `account_accountant` 2. Go to Accounting Dashboard > Bank > `...` > Transactions 3. Open in the list view 4. Select any number of transactions 5. Type something in the statement field of one of the rows 6. Press Create and Edit to create a new Statement 8. Save the statement Ticket [link](https://www.odoo.com/odoo/project.task/5352277) opw-5352277
This update corrects a mistake in how tax reports are generated for the French (l10n_fr) version of Odoo. Specifically, a calculation error in box 15_1 was identified and resolved. This ensures accurate tax reporting for French businesses using Odoo.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/869f80b466ec2246f27e11fa823eb32ac664fb01 we made a mistake in the box 15_1. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243099 Forward-Port-Of: odoo/odoo#243013
This update fixes an issue where public channels were incorrectly configured, defaulting to an internal user instead of a public setting. The change sets the `group_public_id` to `None` to ensure channels are correctly identified as public, improving channel visibility and functionality.
Original PR description
Since #206619, the fixed test has used a wrong value for `group_public_id`, as if it's not set, the default is `Internal User`. This change sets it to `None` to make the channel public. Forward-Port-Of: odoo/odoo#243237
This update resolves an issue where user avatars in the Odoo Chat UI were appearing distorted or incorrectly sized. The fix applies a standard image scaling style ('object-fit: cover') to ensure avatars are displayed correctly and consistently. This improves the user experience and visual appearance 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#242912 Forward-Port-Of: odoo/odoo#242320
This update fixes a potential issue where payroll calculations 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 inaccurate pay slips and ensuring correct 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#98114
This update resolves an issue where payment reports were sometimes generated with inconsistent formats, leading to potential data discrepancies. The fix ensures all payment reports, regardless of the company or installed localization module, use the standard, expected export format. This improves data accuracy and reliability for financial reporting.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#100126