Friday, April 10, 2026
20 changes · saas-18.2
Enhancements to existing features
Module updates no longer show warning-level messages for expected temporary company-specific field adjustments. This prevents healthy Odoo.sh production branches from appearing in a warning state when the update is actually proceeding normally.
Original PR description
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the…
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet. But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine. Current behavior before PR: Logs may contain warnings such as: - Patching res.partner.ref with company_dependent=True - Patching product.template.sale_ok with company_dependent=True - Patching product.product.default_code with company_dependent=True even though there is no actual issue (ok normal behavior) The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine. Desired behavior after PR is merged: Keep the same mechanism, but lower the log level from WARNING to DEBUG. This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG. Having the production branches green. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258326
The invoice sending wizard now only preselects Peppol when the company is actually registered on Peppol, not just because Peppol is available in its country. This reduces confusion and helps prevent users from choosing an unavailable sending method.
Original PR description
Previously, the send wizard would automatically enable the send "by Peppol" option whenever Peppol was available for the company's country. This behavior was misleading, as it didn't check whether the company was actually registered on Peppol. This commit ensures the option is only enabled for companies that are registered on Peppol. task-6044073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254671
The e-invoicing tax extension now includes the full set of Peppol tax exemption reasons. This helps businesses produce more complete and compliant electronic invoices where exemptions apply.
Original PR description
Some tax exemption reasons were missing, This commit ensures having all the tax exemption reasons introduced by Peppol task-6048561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257174 Forward-Port-Of: odoo/odoo#254841
Resolved issues and error corrections
Changing a contact's name no longer overwrites a bank account holder name when that holder name was customized. The holder name still follows the contact name when both previously matched, preserving expected automatic updates while protecting user-entered banking details.
Original PR description
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name"…
**steps to reproduce:** 1. Create a contact 2. On the accounting tab, add one bank account 3. Change the name of the contact 4. The record's name updates automatically the field "Account Holder Name" **problem:** When changing a profile's name in the contacts app, the account holder name changes to be the same as the profile's name. **expected behaviour:** "Make the account holder name update if partner.name is changed ONLY if they were the same before the change. Otherwise keep the account holder name as is." - Referenced from the feature ticket: 5222712 That means if contact's name is the same as the account holder name, then any change to the contact's name, should as well update 'account holder name' accordingly, but if you changed the account holder name itself, then you change contact's name (if they're not the same) then the account holder name shouldn't be updated to match the contact's name. **cause:** The account holder name depends on `partner_id.name` https://github.com/odoo/odoo/blob/2394a9a7f0ece2d5a2185fa4e715d943fc044733/odoo/addons/base/models/res_bank.py#L104-L107 So whenever you change the contact's name, the account holder name changes accordingly. **Fix:** Upon creation, the account holder name is set to the partner name if no name is provided. Additionally, when the partner name changes, the account holder name is updated only if it previously matched the partnername; otherwise, it is left unchanged. **NOTE:** This is a backport of this PR: https://github.com/odoo/odoo/pull/233965 opw-5913464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248886
Miscellaneous changes
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258156
Original PR description
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258156
This fix updates an automated website forum test so it follows the correct editing steps when placing content in a forum cover section. It helps ensure form elements can still be added reliably to forum pages, reducing the risk of editing issues reaching users.
Original PR description
This commit fixes the incorrect steps in the forum_cover_dropzone tour added in #257527. The tour util adding the s_text snippet was removed to add a snippet using the drag and drop method. The snippet added was changed to form snippet to also check that forms can be dropped in the s_cover in website_forum. Forward-Port-Of: odoo/odoo#258061
The Employees demo onboarding and offboarding activity plans now use the base company instead of being company-less. This ensures departments appear in the selection list in single-company setups, avoiding confusion when configuring demo activity plans.
Original PR description
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The…
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The dropdown is empty even if department exists. This can be check by creating a new plan and trying to assign departments to it. # Cause The demo data for thoses two plan explicitely sets the company_id to false : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L21 https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L48 But the department_id has check_company set to true : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/models/mail_activity_plan.py#L12 # Proposed solution Backport of this commit : https://github.com/odoo/odoo/pull/240167 opw-6058697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255842
This fix improves how the HTML editor handles focus in text areas, preventing editing fields from behaving incorrectly after focus changes or cleanup. It helps ensure a smoother and more reliable editing experience for users working with rich text content.
Original PR description
Before this commit: in #253638 we override the focus function of the editable to focusEditable. A patch for textarea and resetting the focus function at destroy is introduced at the forward port 19.0. After this commit: we backport the patch from c9c2325a966db5abf61810000234042f45ef1728 task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257481
Email notifications sent to salespeople for newly created invoices now show the proper invoice reference and amount instead of missing or zero values. This helps recipients quickly identify the related invoice and its value without confusion.
Original PR description
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue:…
Steps to produce: --- - Install `Sales` module. - Create a sale order, set a product, and assign Marc Demo as salesperson in the Other Info tab. - Confirm the sale order and create an invoice. Issue: --- - In the email notification sent to the salesperson, the record reference displays as False and the amount shows as 0.00. Root cause: --- - Here at [1], the record name is False because the invoice is still in draft state. - In [18], _sync_invoice sets amount_currency = line.balance for new lines, but balance is precomputed as 0 before the INSERT because _compute_balance returns 0 for invoice lines. In [17] it read price_subtotal directly, which is always correct. - In 17.0 the same mail fires at the same moment, but _sync_invoice had already set balance = −295 and amount_currency = −295 from price_subtotal, so the email reads the correct 295.00. Solution: --- - Use record.display_name instead of record.name, as display_name is always present regardless of the record state. - Use the tax totals amount instead of amount_total, which is not yet computed on draft invoices. [1]https://github.com/odoo/odoo/blob/0bcc34ec2f92b9b95cde321423d810002bb317ce/addons/account/models/account_move.py#L6478 [18]https://github.com/odoo/odoo/blob/b0a50104a12b205958316d382b4c7b2176395877/addons/account/models/account_move_line.py#L1566-L1610 [17]https://github.com/odoo/odoo/blob/73c076893de79df5a86aa970fde46a7aacbeaf3d/addons/account/models/account_move_line.py#L1536-L1585 Before: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/48c2dc03-765a-49c3-bad3-fd0b14405786" /> After: --- <img width="400" height="175" alt="image" src="https://github.com/user-attachments/assets/53682171-155f-46b3-85dd-0c7c98482067" /> opw-6023827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254862
Belgian province names have been updated to use their native-language forms because these names cannot be translated elsewhere in the system. This helps users see accurate local names in country and address data.
Original PR description
The `name` field of `res.country.state` is not translatable. For that reason we want to have the province names in their native language. [opw-6107258](https://www.odoo.com/odoo/project.task/6107258) Forward-Port-Of: odoo/odoo#258339
Purchase order lines now keep the correct product name when users move between pages in the order form. This prevents confusing name changes while still allowing buyers to search products using vendor codes or vendor names.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#240515
This fix ensures that automated Chrome browser processes are fully closed after tests, including any child processes left behind. It reduces flaky test behavior, lingering network activity, and cleanup failures when test browser profiles need to be removed or recreated.
Original PR description
It's not clear when it started to happen (possibly forever), but apparently waiting for the main chrome process to terminate does not ensure all subprocesses are also terminated. Depending how long these subprocesses stick around, this can lead to: - remaining http or websocket requests - the inability to delete or re-creation of the user directory - possibly other confusing situations Update the chrome termination flow to make sure every subprocess is gone before proceeding to the next step. Kinda-sorta backport of #258062 Forward-Port-Of: odoo/odoo#258069
This fix ensures Danish localization account data is linked using the correct company field during migration. It helps prevent account setup issues for companies using the Denmark localization after upgrading.
Original PR description
Fixes https://github.com/odoo/odoo/pull/257623. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257852
This update fixes a misleading warning related to employee sick leave durations. Previously, the warning incorrectly flagged employees with sick leaves exceeding 31 days. The change now accurately identifies employees who have been on sick leave for at least 31 days, ensuring more accurate reporting.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
This update resolves a bug where only the last employee to clock in at a Point of Sale (PoS) session was successfully recorded. The fix ensures that all employees attempting to clock in simultaneously are properly recognized, improving PoS session management.
Original PR description
If you have multiple employee trying to clock in at the same time in a PoS session, only the last one will actually be clocked in. Steps to reproduce: ------------------- * Setup a PoS to use the blackbox * Activate the multi employee on the PoS * Open the PoS with employee A * Open the PoS on another device/browser with employee B * Try to add a product with employee A > Observation: You get an error saying you are not clocked in Why the fix: ------------ The `employees_clocked_ids` was used as a list of ids and not a list of employees/user. But when a session synchronisation was triggered the `employees_clocked_ids` would become a list of employee/user instead of a list of ids. This would cause `checkIfUserClocked` to fail because it was comparing employee object with ids. opw-6034985 Forward-Port-Of: odoo/enterprise#112323
This update fixes an issue where the Helpdesk return wizard incorrectly included receipt operations in the available pickings. The fix specifically excludes receipts from the wizard's domain, ensuring users only see deliveries when returning items. This improves the accuracy and usability of the return process.
Original PR description
Steps to reproduce: - 1. Create a Sale Order for a customer and fully process the delivery. 2. Create a Helpdesk ticket for that customer. 3. From the ticket, click the 'Return' button to open the wizard. 4. Select the sales order or open the 'Delivery to Return' dropdown. Issue: - The list of available pickings shows both receipts and deliveries operations. Fix: - The domain for the return wizard is updated to explicitly exclude receipts. Note: - This bug is present until saas-18.4. From 19.0 onward it is already fixed in this PR: https://github.com/odoo/enterprise/pull/90371 task-5075205 Forward-Port-Of: odoo/enterprise#95418
This update resolves an issue preventing non-stock users from duplicating Helpdesk tickets with associated sales. The fix sets the product ID to 'False' during duplication, allowing users without stock access to create copies of tickets and their linked sales records. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#101338
This update corrects a bug where the product count in the stat button on Sale Order Lines created from tasks would incorrectly display '0 products' until the task was saved. Now, the counter accurately reflects the products in the order line, regardless of whether the task is saved immediately.
Original PR description
Previously, when creating a Sale Order Line on the fly from a task, the product count in the stat button showed '0 products' until the task was saved. Now, the counter no longer drops to 0 when the record is not saved. task-4276677 Forward-Port-Of: odoo/enterprise#113334 Forward-Port-Of: odoo/enterprise#95100
This update resolves an issue where material resources with assigned roles were incorrectly displayed when filtering by employees in the Planning app. The fix improves the filter domain to accurately exclude these resources, ensuring that only employee-type resources are shown when filtering by employees. This improves data accuracy and reporting.
Original PR description
Steps to Reproduce: 1. Open the Planning app. 2. Go to Configuration -> Materials. 3. Set a role on either the demo material resource laptop or toolkit. 4. Go back to the Planning view. 5. Apply the view filter employee (filter by Employees). Issue: The material resource with a role should not be visible, but it is still present. Current behaviour: When filtering the Planning view by Employees, material resources with an assigned role remain visible. Expected behaviour: Material resources with an assigned role should be excluded from the Planning view when filtered by Employees — only employee-type resources and resources on which role is not set should appear. Fix: Improved the filter domain so unnecessary data are excluded. Task-4526989 Forward-Port-Of: odoo/enterprise#92816
A recent update resolved a bug in the annual tax report that caused the system to crash when comparing values containing text. This fix ensures the report functions correctly regardless of the data types used within the report, improving stability and reliability for users. The change addresses an issue where the system incorrectly processed string values during comparisons.
Original PR description
To reproduce: - Create a company in LU - Open the annual tax report for LU - Click on the comparison filter, compare with 1 period in the past ==> Traceback. This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string. Forward-Port-Of: odoo/enterprise#112619