Monday, October 27, 2025
13 changes · saas-18.4
Resolved issues and error corrections
This fixes an unstable automated test for the website builder sidebar behavior. It reduces false failures caused by timing issues, helping teams validate website changes more consistently without affecting customer-facing functionality.
Original PR description
Tour added in that [commit], was previously failing and the earlier [fix] only reduced the frequency of failures. However, it still occasionally fails due to race conditions of the iframe becoming ready and the moment the builder opens the block tab after the iframe has been reloaded. This commit aims to fix it. [commit]: odoo@a5455bf [fix]: https://github.com/odoo/odoo/commit/0a9522792cc0e18a895c0589f34977123d091d1a runbot-233438
This change adds a safeguard to ensure invoice PDFs show the correct product information when a line has an added description. It helps prevent a past issue where the product name could be omitted from printed invoices, improving invoice clarity for customers.
Original PR description
Issue: If a description is added on a product line, the printed invoice PDF only shows the description without the product name. Purpose of this PR: To add a test to ensure that the product description is correctly reflected on invoice PDF. Original issue was fixed by this PR: https://github.com/odoo/odoo/pull/222589 opw-4985815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French FEC imports now use a valid debit account for rounding differences after a chart of accounts change made the previous account code a grouping account. This prevents import issues and helps ensure accounting data is posted to the correct usable account.
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
This fixes unreliable automated checks around two-factor authentication setup by making the test steps wait for clearer completion signals. The change helps reduce false failures in testing environments, improving confidence in releases without changing user-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
Corrects how Peppol verification status changes are logged for contacts. This ensures the system records the expected verification information even when multiple identifier checks are involved, improving traceability for electronic invoicing setup.
Original PR description
Failed fw-port in https://github.com/odoo/odoo/pull/231142. The logging won't happen if a value is found for the second tested EAS. task-none Forward-Port-Of: odoo/odoo#232900
Saving departure notes for archived employees no longer triggers an error. This prevents interruptions for HR users when maintaining employee records after departure.
Original PR description
Html fields are not part of the supported fields for tracking, see https://github.com/odoo/odoo/blob/11289fd128827587f6ed3fc5beed28f461c0e039/addons/mail/models/mail_tracking_value.py#L49 This causes a traceback when saving the `departure_description` on an archived employee. Added in https://github.com/odoo/odoo/commit/aa4d13b89b4497d2e5b33faa49ad86e0788782a2 Previous related fix: 9b723e2591224f2b563924d3b3dfe27ab909b7d0 opw-5140525
This fix prevents users from creating a new workplace directly from certain Swiss payroll forms when that shortcut could trigger an error. Users can still select existing workplaces, while avoiding a confusing failure during employee or contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
This fix prevents messaging and live chat screens from breaking when a channel member is loaded without full profile details. The system now safely falls back to an existing “unnamed” label, keeping conversations accessible in flows where member identity details are not needed.
Original PR description
Sometimes, channel members are received without their partner/guest because it's not important in the flow. However, some part of the JS code assume the persona is always set, resulting in errors. This PR guards access to persona when computing the member name, a fallback to "unnamed" is already in place. task-5184408 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#233056
Payroll now checks the correct document template separately for each payslip. This prevents cases where one payslip's missing or different template could affect others, helping ensure payroll documents are generated with the right layout.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
German e-invoices now use the actual customer or parent company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in XML invoice data when they are not shown on the customer-facing PDF.
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
Email Marketing templates using the showcase block now keep their separator styling after saving. This ensures recipients see emails as designed, improving visual consistency in campaigns.
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
Internal users who click the View Product button in product-related emails are now taken to the internal product page instead of the public shop page. This keeps staff workflows accurate while preserving the public shop redirect for portal and public users.
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
Contact addresses now include the second street address line when generating the complete address. This ensures emails and other documents show the full address for contacts who use an additional address line.
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