Monday, September 22, 2025
21 changes · saas-18.4
Resolved issues and error corrections
Spanish translations for Peruvian tariff fractions and withholding codes were corrected so users see the right wording in localization workflows. This helps reduce confusion and supports more accurate Peruvian electronic document handling.
Original PR description
## Issue: The latest `tariff_fraction` entries were not properly translated into Spanish There were also inconsistencies in the translation of some `withhold codes` ## Cause: The `.po` and `.pot` files were not correctly populated In addition, the translation of "Others" in `l10n_pe_withhold_code` conflicted with `l10n_pe_edi_reason_for_transfer__13`, because the `msgid` is the same but not the `msgstr` should be different opw-4741731 Forward-Port-Of: odoo/enterprise#95019 Forward-Port-Of: odoo/enterprise#92758
This update ensures invoices for foreign customers use an alphanumeric Other Buyer ID in Saudi e-invoicing XML. This helps avoid ZATCA acceptance warnings and supports smoother invoice compliance checks.
Original PR description
When an invoice is being issued to a Foreign Customer, the Other Buyer ID (Other Buyer ID (BT-46) <cac:AccountingCustomerParty / cac:Party / cac:PartyIdentification / cbc:ID>) should be OTH and filled accordingly to avoid an acceptance warning from ZATCA. According to ZATCA, the value needs to be in alphanumeric format, even if the value does not follow the specific country's VAT format Task-id: 5075005 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#227294 Forward-Port-Of: odoo/odoo#226593
The website editor now correctly hides the image width setting when an image is placed inside a card. This restores expected behavior and helps prevent users from applying layout options that do not make sense in that context.
Original PR description
When converting the options to Owl, the behavior from commit [1], which hid the image width option for images inside cards, was lost. We are reintroducing it here. [1]: https://github.com/odoo/odoo/commit/4dcd1f9607ecc1ea932e02128a3e6f01d652cba6
Event track emails now use embedded image-based icons instead of relying on external icon fonts that many email systems do not support. This ensures recipients see the intended visual elements consistently in their invitations or notifications.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed. This commit replaces i tags with font awesome classes in mail by images. Task-5082165 Forward-Port-Of: odoo/odoo#226331
The automation rule trigger dropdown now uses the correct background color when dark mode is enabled. This removes a visual inconsistency, making the interface easier to read and more polished for users working in dark mode.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226666 Forward-Port-Of: odoo/odoo#226116
This fix prevents an error when a Chilean electronic tax document is imported more than once. Users now receive the intended message instead of encountering a system traceback, improving reliability for Chilean accounting workflows.
Original PR description
### Steps to reproduce: - Install 'l10n_cl_edi' and switch to a Chilean company - Import twice the same DTE XML file. ### Cause: This [commit](https://github.com/odoo/enterprise/commit/42744fcecdbd36ea0101070c68299227a9f204a6) forgot to add the `_()` method to format the message. As `append()` only needs one argument but two are given, there is a traceback. opw-5080094
This fix ensures contracts with no amount due are no longer incorrectly marked as needing an invoice. It helps teams avoid unnecessary invoice follow-up work and keeps subscription billing status accurate.
Original PR description
Forward-Port-Of: odoo/enterprise#94626
This fixes an error that could occur when point-of-sale orders calculated external taxes through AvaTax. Removing the outdated reference helps ensure tax data can be prepared without interrupting checkout or order processing.
Original PR description
Since [this PR](https://github.com/odoo/enterprise/pull/82623), defination of `_get_lines_eligible_for_external_taxes` was removed but a reference to it still remained, causing the following error when calling the `_get_line_data_for_external_taxes` method:. `AttributeError: 'pos.order' object has no attribute '_get_lines_eligible_for_external_taxes'` Fix: Removed reference to `_get_lines_eligible_for_external_taxes` from `_get_line_data_for_external_taxes` at [1]. [1]- https://github.com/odoo/enterprise/blob/9a1544d19c1f5f3546c04022a11601df43199d10/pos_avatax/models/pos_order.py#L15-L18 sentry-6843827499
Approval demo data no longer adds the same administrator approver twice. This prevents duplicate approval entries when users open their approval requests, keeping demo approval workflows cleaner and less confusing.
Original PR description
steps to reproduce: - install approvals with demo data - click on My approvals > My requests Issue: - approval category sets approver `user_admin` and demo data also sets `user_admin` as approver so it creates double entry for `user_admin` in DB Fix: - removed `user_admin` in approval request because it will be added directly through approval category task-4677549
The website editor now correctly applies the “Code” label option for multilingual language selectors. This fixes a display issue where choosing language codes still showed the full text label, helping sites present compact language choices as intended.
Original PR description
Scenario: - have more than one language on website - edit website page - select the lang selector - change Language Selector > Label to Code Result: the render is the same than "Text" Cause: the view website.header_language_selector_no_text that should be enabled for code label type is missing from the website builder refactoring (9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2). opw-5022850
Single-company databases can now detect duplicate records even when the company field differs. This makes data cleanup more reliable and helps users merge duplicate records that were previously missed.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408 Forward-Port-Of: odoo/enterprise#94797 Forward-Port-Of: odoo/enterprise#93184
The website editor now shows newsletter mailing list names without extra numeric identifiers when adding checkbox options. This makes the form setup clearer for users and helps avoid confusing labels on newsletter subscription forms.
Original PR description
In the "Subscribe to newsletter" form, "Add new Checkbox" on the web editor for "Subscribe to" field lists mailing list with number. This commit removes the number by fetching the records from mailing list via "name" and not "display_name". Steps to Reproduce: 1. Add a form 2. Change action to "Subscribe to Newsletter" 3. Click on "Subscribe to" field 4. Click on "Add new Checkbox" and you see the numbers on the list. opw-4730089 Forward-Port-Of: odoo/odoo#210891
Users can now open the debug Data view on records that include field properties without triggering an error. This makes troubleshooting and support workflows more reliable when custom or dynamic property fields are present.
Original PR description
Example Steps: - Install `crm` - Add a random field properties in a random form view - Enable debug mode - Open debug menu - Select Data - Traceback ```py raise ValueError(f"Invalid field…
Example Steps:
- Install `crm`
- Add a random field properties in a random form view
- Enable debug mode
- Open debug menu
- Select Data
- Traceback
```py
raise ValueError(f"Invalid field {field_name!r} on model {self._name!r}")
ValueError: Invalid field 'properties.xyz' on model 'x.y'
```
There are two causes for this problem.
First, we use orm.read to retrieve data from records, which does not directly handle sub-field properties. We only need to use `definition_property` (which contains the overall schema of the JSON field).
Second, when displaying the data, we use JSON.stringify with `replacer`:
```js
get content() {
const record = this.props.record;
return JSON.stringify(record, Object.keys(record).sort(), 2);
}
```
In this case, replace contains all the keys present in record, sorted. The problem is that the properties fields are themselves objects that contain the keys: `name`, `string`, `type`, `default`, `value`.
And giving an array to replace in `JSON.stringify` will filter the keys and keep only those that are whitelisted in it.
```js
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
const foo = {
foundation: “Mozilla”,
model: “box”,
week: 45,
transport: “car”,
month: 7,
};
JSON.stringify(foo, [“week”, “month”]);
// ‘{“week”:45,“month”:7}’, only keep ‘week’ and “month” properties
```
This will ignore the keys of the properties fields.
The fix is therefore to sort the object before stringifying it, without using replace.
Thanks to these two fixes, the data is displayed as expected, regardless of whether there are field properties or not.
opw-5017425
Forward-Port-Of: odoo/odoo#225572
Forward-Port-Of: odoo/odoo#224084A test setup was corrected so discount and pricelist settings are enabled when needed. This prevents automated checks from failing in sales-only scenarios, helping keep releases reliable without changing customer-facing behavior.
Original PR description
This commit fix runbot issue cause by PR https://github.com/odoo/odoo/pull/226859 to compute discount depending on pricelist. Cause: - In subscription discount and pricelist are default enable that allow discount to compute properly and set it to 0 but when only sale is installed test was breaking because non of the condition was enabled require to compute discount properly. Fix: - Enabled discount and pricelist feature in testcase to compute discount properly runbot-232685
Fixes a crash that occurred when users tried to translate a chatter message from the mobile action menu. Mobile users can now use message translation reliably without being interrupted by an error.
Original PR description
Steps to reproduce: - Open any chatter with a message on mobile - Try to translate the message using the Translate mobile action => Throws traceback This happens because the component here is `MessageActionMenuMobile` instead of `Message`, and MessageActionMenuMobile does not have the `onClickToggleTranslation` method. This PR fixes the issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227578 Forward-Port-Of: odoo/odoo#223567
This fixes a Point of Sale restaurant issue where orders could be incorrectly marked as needing preparation when no preparation printer or display categories were configured. Staff can now proceed with payment without seeing an unnecessary preparation prompt, reducing confusion during checkout.
Original PR description
Steps to reproduce: - Open a pos restaurant config that has no prep printer/display. - Add an orderline. - The order button appear and if you try to pay the popup ask for send to preparation is shown. Issue: If there is no preparationCategories for a config getOrderChanges consider that all the available categories are the preparationCategories. Fix: If there is no preparationCategories, set the orderline uiState hasChange to false. Note: When no preparation printer category is defined, no categories is to be return by default. For the preparation display, if no preparation categories is selected preparationCategories will return all the available categories. Task-5016231 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#222950
Restaurant POS orders no longer ask staff to send items to preparation when no preparation printer or display category is configured. This avoids confusing extra steps during checkout and keeps the order flow aligned with the restaurant setup.
Original PR description
Steps to reproduce: - Open a pos restaurant config that has no prep printer/display. - Add an orderline. - The order button appear and if you try to pay the popup ask for send to preparation is shown. Issue: If there is no preparationCategories for a config getOrderChanges consider that all the available categories are the preparationCategories. Fix: If there is no preparationCategories, set the orderline uiState hasChange to false. Note: When no preparation printer category is defined, no categories is to be return by default. For the preparation display, if no preparation categories is selected preparationCategories will return all the available categories. Task-5016231 Forward-Port-Of: odoo/enterprise#92541
Survey invitation emails now correctly refresh their subject when a selected email template has been changed. This prevents outdated subject lines from being sent and helps teams keep survey communications consistent.
Original PR description
Description of the issue/feature this PR addresses: Fixed [previous commit] where the subject doesn't update when the template was updated. This was due to a filter in place preventing this from happening. Steps to reproduce on runbot: 1. Go to mail templates and search for Survey 2. Open the Survey: Invite template 3. Update the subject on this template 4. Open the Surveys app and select any survey 5. Click on Share and then enable send by email 6. Change the template being used 6. The subject will stay the same [previous commit]: https://github.com/odoo/odoo/commit/16a2c28c9aec307f7ce9dbed0a660b512db31f3a opw-4654411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227460 Forward-Port-Of: odoo/odoo#221049
This fix prevents an error when opening Studio from a newly created Project dashboard. It handles the case where no project update record exists, so users can customize the view without triggering a server error.
Original PR description
An error currently occurs when opening the studio view. Steps to reproduce: --- - Install `Project` and `web_studio` - Project > Configuration > Projects > Create a New Project - Click on the `Dashboard` button > Open studio view - Error in terminal Traceback: --- `TypeError: object of type 'bool' has no len()` This error occurs because `project.update` doesn’t have any records. When opening the studio view, at [1] it tries to compute the record’s name, which is `False`, and `False` has no length. [1]- https://github.com/odoo/odoo/blob/e0322e2cbc16d2405e66f3b16cbabeac2ad265e7/addons/project/models/project_update.py#L80 sentry-6830573412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the project side panel from failing when two project-related extensions use the same display order for statistic buttons. Business users benefit from a more reliable project view, especially in databases with multiple installed modules or customizations.
Original PR description
Description of the issue/feature this PR addresses: If a sequence in function _get_stat_buttons in project.project is repeated, the view view fail because we are using the sequence as key Current behavior before PR: If we repeat a sequence in two independent modules, the view fails. Desired behavior after PR is merged: The view works as expected --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227382
A mislabeled language setting in the Dutch balance sheet report was corrected so the affected term appears under the intended German language code. This helps ensure financial reports show the right localized wording for users working with translated statements.
Original PR description
One term in the Dutch balance sheet was having the `nl` language code instead of `de`. This commit corrects that. Forward-Port-Of: odoo/enterprise#95118