Friday, January 30, 2026
19 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where dynamic product snippets would cause horizontal scrolling when the content width was set to 'max'. The fix repositions the navigation buttons to prevent this, ensuring a consistent and user-friendly experience across larger devices. This improves the visual presentation of product listings.
Original PR description
Steps to reproduce: 1. Drag and drop the dynamic products snippet. 2. Select it and change the content width to **max**. Issue: When the content width is set to **max**, an unnecessary horizontal scroll appears. Reason: The issue occurs because the `previous` and `next` navigation buttons were not properly positioned. Fix: For devices larger than "mobile", the `previous` and `next` buttons are re-positioned, horizontally inward by "**50%**" of their own width with the help of `transform` property. This keeps the controls within the visible area and prevents horizontal scrolling. task-5090468 Before: <img width="1915" height="966" alt="image" src="https://github.com/user-attachments/assets/0c20d0b6-32cc-477b-8403-55bb0d372d8d" /> After: <img width="1920" height="963" alt="image" src="https://github.com/user-attachments/assets/4194b0f1-f3ad-4818-aa6f-2fda4561d2c7" /> Forward-Port-Of: odoo/odoo#237876
This update corrects a bug that prevented new partner records from being created when attempting to add them to an existing recordset. The issue stemmed from a mismanaged 'self' variable within the partner creation process. This fix ensures correct record handling during partner creation, improving data integrity.
Original PR description
**Issue:** `ValueError: Expected singleton` when creating new partners on a non empty (no singleton) recordset due to the `_add_missing_default_values` call. The default create method uses `self = self.browse()` to remove the records, but the `res.partner` override was still using its original `self`. **Fix:** Properly call the method on an empty recordset. related: https://github.com/odoo/odoo/commit/79486ec3fc553845cac14fb135c16fe0b093e3b4 opw-4932114
This update fixes an error in the French Profit and Loss report (`l10n_fr_reports`) where account 649 was incorrectly placed. The change aligns with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within 'Wages and Salaries' and 'Social Security Charges'.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update ensures that WebGL testing continues to function correctly in Odoo's automated tests, even with recent changes in Chrome. Because SwiftShader (a software renderer) is now the default fallback for Chrome 144 in headless mode, this change re-enables WebGL to maintain testing of features like image filters. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves an issue where editing a bank statement line caused unnecessary recalculations of all related lines, including reconciled ones. The change now ensures that only the edited line is recomputed, improving performance and stability when working with bank statement data. This optimization enhances the user experience and reduces processing time.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885
This update ensures that the current day location field is consistently included when retrieving data for the homeworking feature, particularly in scenarios like creating many-to-many relationships in Studio. Previously, this data was sometimes missing, causing issues. This fix guarantees accurate location information is provided, improving the functionality of the homeworking workflow.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 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 Forward-Port-Of: odoo/odoo#246096 Forward-Port-Of: odoo/odoo#245740
This update resolves a confusion for users of the account_peppol module. Previously, a setting was configured as 'demo' while another related setting was 'test'. This change ensures a consistent and clear setup process, improving usability and reducing potential errors.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update resolves a bug where the serial number assigned to products on 'ready' pickings was incorrectly updated during delivery order creation. The fix prevents unnecessary serial number changes, ensuring accurate tracking of stock and serial numbers. This improves data integrity and reduces potential errors in inventory management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
This update resolves a technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization functionality operates correctly, preventing potential disruptions to data synchronization. It's a routine maintenance update.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update fixes an issue where some Odoo records wouldn't open correctly in their default form view. The change ensures that other views are enabled when opening records, providing a smoother and more reliable user experience. This resolves a technical glitch that impacted record access.
Original PR description
Records of some models may not want to be shown in their form view by default. See related ENT PR for documents. We re-export to avoid patching order issues. In particular, this makes sure that if we are in the webclient, the chat window is opened before executing the "real" open. Task-5386466 Forward-Port-Of: odoo/odoo#246173 Forward-Port-Of: odoo/odoo#244289
This update prevents documents from automatically opening in a form view when accessed through various channels like links or notifications. Previously, users were unexpectedly directed to the document's form, which has now been corrected to align with how documents are accessed in other views. This improves the user experience and ensures consistent document access.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466 Forward-Port-Of: odoo/enterprise#105809 Forward-Port-Of: odoo/enterprise#104622
This update resolves a test failure caused by a recent change to the payment method processing logic in the l10n_uy_edi module. The commit simply adds the necessary update to the test suite to account for the new method extension, ensuring the system continues to function correctly.
Original PR description
The PR odoo/odoo#244443 introduces a new extension to the method _is_downpayment hence the test fails since it is not patched. This commit adds the new extension to the patched list. task-5135918
A bug was causing the input field in the campaign test dialog to disappear, requiring users to close and reopen the dialog to use it. This fix addresses a technical issue related to how the system handles empty input fields, ensuring the field remains visible and functional. The scope was limited to the marketing automation module for efficiency.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
This update corrects a warning message appearing in the sales module. The previous code incorrectly processed multiple sales leads at once, leading to an error. This change ensures that each sales lead is handled individually, resolving the warning and improving system stability.
Original PR description
### Issue: In #244061 changes, the expired so leads to warning message. However, the batch `res_id` is used instead of single record which is an error. opw-5478691 Forward-Port-Of: odoo/odoo#246369
This update fixes a technical error that could occur when changing the timesheet invoicing policy after a sales order was created and then the user who created it was deleted. The change ensures the system correctly handles scenarios where the original user's information is no longer available, preventing a traceback and maintaining proper policy application.
Original PR description
Steps to reproduce: 1. Create a new user in the database 2. Create a new sales order as the new user 3. Add an order line where the product is of type "Service" and has an invoicing policy of "Based on Timesheets" 4. Confirm the sales order 5. Sign out of the new users account and sign in as admin 6. Delete the newly created user 7. Go into Settings > Timesheets > Invoicing Policy 8. Attempt to change the policy to "Validated timesheets only" 9. Save your changes 10. Observe the traceback The `if` statement would trigger if any record in the recordset had a `create_uid`, which would cause a traceback if the first record in the recordset happened to not have a `create_uid`. This can occur if the user who created a given sale order is deleted from the database. This change will ensure that the function correctly falls back to the currently signed in user if the sale order create_uid doesn't exist. opw-5868538 Forward-Port-Of: odoo/enterprise#105687
This update corrects an issue where text within Odoo views was unexpectedly removed when a field was restricted through access controls. Previously, this created inconsistent and confusing view layouts. This fix ensures that all text remains visible after a field is removed, maintaining a consistent user experience.
Original PR description
In a view, if a field is removed due to security access restrictions, the text that follows it is not preserved. This leads to inconsistencies in the view. opw-5798852 Forward-Port-Of: odoo/odoo#246238 Forward-Port-Of: odoo/odoo#245855
This update fixes an issue where product names weren't consistently displayed in the correct language based on the user's selected language setting. Previously, repeated access to the product name within a method would default back to the initial language. Now, the system always uses the current language context when generating product names, ensuring accurate display for all users.
Original PR description
Description of the issue/feature this PR addresses: Compute of display_name in different languages that can be returned incorrect Current behavior before PR: When accessing two times in the same method the display_name of a configured product but the second time having a .with_context(lang=lang) other than the previous language, the returned display name will not be in the specified language as the cached value will be returned. Desired behavior after PR is merged: _compute_display_name should always take into account a change of language in context when the value is accessed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242829
This update resolves an issue where a technical error during bill import could cause duplicate entries in our PEPPOL integration. The change ensures that these errors don't block the import process and allows bills to be left unlinked, improving the reliability of our data synchronization.
Original PR description
Backport of https://github.com/odoo/odoo/commit/71de6902d73bec32f93e3be8f4de4ec89e9dc987 A UserError there can cause duplicates in peppol fetching. It should never block an ack. We can leave them unlinked We also do the same for any unexpected error that occurs after we've created the move. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246475
This update resolves an issue where a 100% discount combined with shipping costs caused a technical error in the Express Stripe checkout form. The fix adjusts how zero minor amounts are handled, ensuring the checkout process functions correctly when discounts are applied. This prevents errors and allows for accurate order processing with significant discounts.
Original PR description
### Issue: Due to this issue, there is a traceback, in express stripe checkout when there is a 100% discount and shipping cost. Steps to reproduce: 1- Setup `Stripe` as the only payment provider in the db. 2- Create a discount code with 100% discount on order. 3- Set a fixed price on the delivery method. 4- On shop, add a product to cart, and then enter the discount code. 5- Refresh the page. There is a traceback. #### Cause: This issue is introduced after #209103, which set `minor_amount` to amount excluding delivery. In the case it's 0, it's not going to be rendered on express_checkout view as it is false. Which cause a traceback here: https://github.com/odoo/odoo/blob/8f7e3d588c6c1189e64442a33037666d5d70aae7/addons/payment_stripe/static/src/js/express_checkout_form.js#L73-L81 opw-5482646 Forward-Port-Of: odoo/odoo#246355