Monday, October 27, 2025
11 changes · saas-18.3
Resolved issues and error corrections
The web interface no longer shows an incorrect timezone mismatch warning when a user's computer and profile use the same timezone with a 30- or 45-minute offset. This prevents unnecessary confusion for users in affected regions.
Original PR description
**Steps to reproduce** - Set your machine timezone to one ending in :30 or :45 - Open your user preferences and chose the same timezone Issue: the timezone mismatch icon is displayed. **Cause** `.toFixed(0)` rounds to the nearest integer. **Change** Always round down the hour part. opw-5123025 Forward-Port-Of: odoo/odoo#232813 Forward-Port-Of: odoo/odoo#230274
The French FEC import now uses a valid debit account for rounding differences after the previous account code became an account group. This prevents import issues and helps accounting data load correctly under the updated French chart of accounts.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
German e-invoice XML files now use the real customer or company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in electronic invoice data and keeps it consistent with the PDF invoice.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232819
This update makes automated checks for two-factor authentication setup more dependable by removing timing-sensitive steps. It reduces intermittent test failures under heavy load, helping keep development and release validation smoother without changing customer-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
Sale orders that use only fixed taxes no longer fail when read through XML-RPC integrations. This prevents export or integration errors by ensuring tax total values are returned in a format the system can safely transmit.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a fixed tax; 2. create a sale order using only the fixed tax; 3. read the sale order via XML-RPC. Issue ----- TypeError: cannot marshal None unless allow_none is enabled Cause ----- If only a fixed tax is used, the `_get_tax_totals_summary` method returns a dict where the `display_base_amount_currency` and `display_base_amount` values are `None`, leading to an error serializing the result. Solution -------- As the result gets serialized by `OdooMarshaller(allow_none=False)`[^1], we should use `False` instead of `None`. [^1]: https://github.com/odoo/odoo/blob/b887bf2/odoo/addons/base/controllers/rpc.py#L114 opw-5173477 Forward-Port-Of: odoo/odoo#232517
Draft sales orders now let users click product lines to edit the product or add a description instead of unexpectedly opening the product record. This reduces friction when updating quotes and prevents confusion during routine sales order edits.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Create a sales order; 2. add a product that doesn't have an extra description; 3. save & exit view; 4. go back to view; 5. add a description or change the product on the line. Issue ----- Clicking on the product field opens the product record instead of edit mode. Cause ----- It opens the product record because the `canOpen` property is set to `true`. As this is the default value, and isn't getting changed anywhere, the line will always open the product record outside of edit mode. Solution -------- Instead of using OR, check `props.canOpen` AND additional checks. opw-5172115
This change removes redundant database checks from mail link previews because existing required-field rules already cover them. It helps avoid restore problems when moving database dumps between PostgreSQL versions, though existing databases may still need cleanup before restore.
Original PR description
Same as #229274 these constraints are redundant with `required=True` and cause issues when restoring a dump from pg17 to pg18. And much like #229274 this only fixes databases going forward, on existing databases the constraints have to be dropped on the source.
This fixes an issue in Email Marketing where separators in the showcase email template could appear incorrectly after saving. Recipients should now see the intended email layout, helping campaigns look more polished and consistent.
Original PR description
Problem: When adding the `s_showcase` template in Email Marketing and saving, the separator is not properly rendered in the received email. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 opw-5077992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230773
Fixed an issue where internal users clicking a product link from an email were sent to the public shop page instead of the product record they can access. This helps staff reach the correct product page directly from email notifications while keeping public and portal users on the website view.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281 Forward-Port-Of: odoo/odoo#233030 Forward-Port-Of: odoo/odoo#231961
This update fixes a failing automated test related to chat message bubbles in the Discuss area. It helps keep release validation stable without changing how users interact with the application.
Original PR description
Backport of fix https://github.com/odoo/odoo/pull/227445 Fixes runbot-error-233607 Forward-Port-Of: odoo/odoo#233243
The complete contact address now includes the second street address line when it is filled in. This ensures emails and templates using the full address show complete and accurate contact information.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103