Tuesday, March 17, 2026
13 changes · 19.0
Enhancements to existing features
This update adds automated checks for Gelato product synchronization and purchasing flows in Odoo. It helps reduce the risk of future regressions in Gelato-related sales and website sales processes.
Original PR description
Tests for synchronizing Gelato products with Odoo and buying Gelato products are added. task-4527206 Forward-Port-Of: odoo/odoo#244752
Resolved issues and error corrections
This fixes an unstable automated test in the Mail app that could fail unpredictably when checking notification scrolling. The change makes the test wait for messages to load and confirms scrolling is complete, helping keep development checks reliable without affecting end users.
Original PR description
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element…
Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error: ``` [toBe] expected values to be strictly equal (Element .o-mail-NotificationMessage:contains(notification 0) not found in viewport of .o-mail-Thread) ``` This happens because while the test is awaiting the scrolling to unread, this is made with just an `await tick()` after opening discuss app. This is not enough: messages need to be loaded and then there's a tick with scroll to unread message. The awaiting of messages being loaded was missing in the test, which this error is fixing. This is important because the opening of pinned panel and click on jump may be triggered before the auto-scroll to unread message, and this is a problem because the jump to pinned message would be cancelled by the scroll to bottom. Also instead of awaiting the tick for scroll to unread message, this commit replaces it by assertion of message list being at the bottom. This asserts precisely the scroll has happen, and its ok to have it scroll at bottom as the last message is short and is necessarily smaller than viewport, thus the auto-scroll to this unread message implies this scrolls to the bottom of message list. Fixes runbot-error-238427
This update prevents Brave's automatic dark mode from altering the colors of Point of Sale and self-ordering screens. It helps keep these customer-facing interfaces readable and consistent for users who have browser dark mode enabled.
Original PR description
Users who have enabled the dark mode option in Brave that automatically modifies website colors may experience usability issues with the self-order and point_of faile. To avoid this, a meta tag has been added to disable Dark Reader modifications . Task.6037294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Hungary localization now maps the 0% intra-community goods tax only to EU partner fiscal positions. This prevents non-EU partners from receiving an EU-specific tax treatment, improving tax setup accuracy for Hungarian companies.
Original PR description
In Hungary, the 0% Goods Intra-community tax is mapped with the EU partner & Partner outside the EU, which doesn't make sense. Intra-community taxes should only be mapped with the EU partner fiscal position. This commit removes the outside EU position from this task. no-task
Quote PDFs using the German DIN 5008 layout now keep section rows aligned when composition details are hidden. This prevents section backgrounds from stopping early and keeps report columns visually consistent for customers and sales teams.
Original PR description
Steps to reproduce ================== - Install website_sale,accountant,l10n_de - Select the DE company - In the accounting settings, enable the "Show Position Column in Reports" - Go to Sales - Create a new Quotation - Select a customer - Add a product - Add a section - Click on the three dots - Click on Hide Composition - Add another section - Click on the cog menu - Click on Print > PDF Quote => The background of the first section ends before the end of the line => The columns are also not aligned Solution ======== Add a colspan of 2 to the section names opw-5427590 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
This fix stops automated test runs from leaving behind unwanted Chrome temporary folders. It keeps development and test environments cleaner, reducing manual cleanup and avoiding gradual disk clutter.
Original PR description
It's unclear since when or under what configuration exactly, but Chrome(ium?) seems prone to creating directories called `org.chromium.Chromium.*` (or some variant thereof) in the temp dir (some people report them to be prefixed by a `.`) and never clean them. By telling chromium that its tempdir is its data dir, it creates its litter in there, and we remove the entire thing during cleanup, solving the littering. Forward-Port-Of: odoo/odoo#253350
Archived product templates can now have attributes added without triggering an error or accidental deletion. This protects historical product records and keeps archived products correctly inactive while changes are made.
Original PR description
When adding attributes to an archived product template, an error was raised because the template was incorrectly deleted. This happened because variant counting only considered active variants. Now counts all variants (active and archived) to prevent template deletion, and filters variants before activation to keep them archived when their template is archived. @qrtl QT6449 Forward-Port-Of: odoo/odoo#252927
The employee profile now only shows the emergency contact relationship field when the employee belongs to an Indian company. This avoids confusion for employees in other countries by keeping country-specific payroll details out of their private information form.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
The editor now avoids showing the icon toolbar when users click near content that merely contains an icon, such as a table of contents or rating stars. This reduces confusing popups and makes editing documents and to-do content smoother.
Original PR description
Steps to Reproduce: - Go to To-Do. - Inside a list, insert a Table of Contents. - Click at the top, outside of the Table of Contents. Description of the issue - The icon toolbar appears unnecessarily. Cause: - This happens because the `icon_plugin` checks whether a node’s child contains an icon and, if so, displays the icon toolbar. Although the Table of Contents contains an icon, this condition passes, causing the toolbar to appear. - The same issue can occur with other elements that contain an icon. For example pressing enter before a star element also opens the icon toolbar. Solution: - Remove the condition that checks whether a node’s child contains an icon. task-5954459
This update resolves an issue where the offer simulation in the payroll module was failing when processing contracts that had already ended. The fix ensures the simulation uses a temporary employee version, preventing errors and accurately calculating potential salaries. This improves the reliability of the payroll process.
Original PR description
### Steps To Reproduce: - Go to Payroll > Employees > Salary Calculator - Choose an employee whose contract already ended. - Boom you got an error(In Simulation) ### Issue: - We were using actual employee's version in simulation. ### Fix: - Instead of using existing employee version, use the temporary created employee's version Task: 5936444
This update corrects an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export reports. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger and providing accurate financial reporting. This improves the reliability of the export data for Swedish accounting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
This update ensures that follow-up emails for invoices now send the actual invoice PDF attachment, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDF files, ensuring accurate and complete invoice information is sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#110753 Forward-Port-Of: odoo/enterprise#98820
This update fixes an issue where multiple email addresses associated with a contact were being overwritten when creating a helpdesk ticket. The change ensures that only the primary email address is used, resolving a potential data inconsistency. This improves the reliability of ticket assignments and communication.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808