Monday, September 22, 2025
29 changes · saas-18.4
Resolved issues and error corrections
This fix stops customers from editing rental dates after a rental product has already been added to the cart. It prevents checkout-disrupting errors when invalid date ranges are entered and keeps rental orders consistent.
Original PR description
An error currently occurs when an user attempts to change the rental start date to a value later than the end date while a product is already in the cart. **Steps to replicate:** * Install…
An error currently occurs when an user attempts to change the rental start date to a value later than the end date while a product is already in the cart. **Steps to replicate:** * Install `website_sale`, `stock` , `sale_renting` with demo data * Rental > Products > Printer > Sales > Turn `Out of stock: continue selling` off * Website > Shop > Printer > Select dates when printer is available * Add printer to cart > Set start date greater than end date by typing `ValueError: min() iterable argument is empty` **Cause:** This error occurs because [1] causes the `availabilities` list to be empty at [2] when retrieving combination information. This issue occurs in version `18.4` and later because the date picker remains editable after the product is added to the cart. The changes in [3] remove the `disabled` attribute after the product is added, allowing users to modify the date. **Solution:** * Prevent users from editing dates after a product is added to the cart, as done in version `18.3`, since all products must share the same dates as the one already in the cart, as specified in [4]. [1]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/product_product.py#L79 [2]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_stock_renting/models/website.py#L14-L19 [3]: https://github.com/odoo/odoo/commit/bbb2d98d9ab97ce729d59b9858b63daccf5434e2#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R230 [4]: https://github.com/odoo/enterprise/blob/246a49ff3fd2baa636f3e7d80a75a01e77060ee1/website_sale_renting/views/templates.xml#L100 **Sentry-6803401968**
Fixed an issue where Saudi Arabia invoice PDFs could omit the company logo when another localization module was installed. This ensures printed invoices keep the correct branding and presentation for customers.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_sa_edi` and `l10n_latam_invoice_document` 2. Create and confirm an invoice. 3. Print the invoice PDF issue: ------ The company logo is not…
steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF
issue:
------
The company logo is not printed on the invoice PDF.
cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8
In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23
However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14
solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.
<details>
<summary>Click here to see:</summary>
Before:
<img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>
After:
<img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>
opw-4977422
Forward-Port-Of: odoo/odoo#225476Spanish 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
This fixes bus notifications so users receive updates for both their direct groups and any groups they inherit through roles. It prevents cases where administrators or other users with implied permissions missed automatic Discuss channel updates until manually reloading.
Original PR description
To target users of a group, bus notifications are sent on group records. To do so, user groups are added to its bus subscription. However, since odoo/odoo#179354, only explicit groups are added, not every implied group. It's incorrect. For example, sending on the user channel doesn't notify administrators while it should. Steps to reproduce (note that the steps are only working for admin): - Click the gear button on the sidebar in discuss page to navigate to the channel kanban view as admin - Click the `New` button and create a channel with an internal users group as `Auto Subscribe Groups` - Go back to the discuss main page. The new channel will not be pinned unless you reload the page See: https://github.com/odoo/odoo/pull/179354/files#r1954163704 Forward-Port-Of: odoo/odoo#217543
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
Importing spreadsheet files no longer fails when text fields contain values that look like dates. This helps users re-import exported records, such as pricelists, without errors caused by automatic spreadsheet date formatting.
Original PR description
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date…
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format - Delete the record and test the import the XLSX file #### Uncaught Promise: > Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array) ### Cause of the Issue: The issue is raised by the error message: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432 which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place. #### Details: Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet). However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632 To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value. This fix has two major issues: 1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421 ### Fix: We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text). Note: this may also require an adjustment in master for the html type. opw-4935423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226807
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
The Danish minimal balance sheet and profit and loss reports were corrected so report formulas no longer include extra signs that could produce wrong values. Report labels and translations were also cleaned up for clearer, more consistent presentation.
Original PR description
In the minimal reports of l10n_dk, it appears that some expression ended with a sign and the report engine was given wrong value. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will remove the extra sign to correct the report and also remove the letter or number before the name. This commit will change the translation accordingly to the other commits task-4949062 Forward-Port-Of: odoo/enterprise#94350 Forward-Port-Of: odoo/enterprise#91135
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
Date filters in timesheet forecasting now handle local time zones correctly. This prevents records from being missed or incorrectly included for users in time zones ahead of or behind UTC, improving report accuracy.
Original PR description
This commit fixes the timezone issues with the Date filters, in which we were comparing a UTC DateTime value to a local timezone's Date. In certain timezones, this leads to off-by-one errors in the records fetched from the DB, depending on how far ahead or behind UTC that timezone is. Specifically, we remove the UTC conversion within the filter domains. opw-5068870 Forward-Port-Of: odoo/enterprise#94032
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
Timesheet date filters now use the user's local date instead of a UTC timestamp. This prevents entries from appearing under the wrong day or week for users in time zones where the previous behavior caused off-by-one date shifts.
Original PR description
This commit fixes issues with the timesheet Date filters, in which the `date` field of account.analytic.line records, which is stored as the local timezone's date, is being compared to a UTC DateTime value. This leads to off-by-one errors. For example, if you are in Berlin and try to filter for all timesheet entries from "Today", you will only find entries from the previous day. Similarly, for the "This Week" and "Last Week" filters, which would be shifted by one day. The filter domains have been changed to compare the `date` to the local timezone's "today". opw-5003310 Forward-Port-Of: odoo/odoo#225753
Website form file upload fields now respect the configured maximum number of files. This lets visitors upload multiple files when allowed, while preventing invalid limits below one.
Original PR description
Steps to Reproduce: - Open the website module. - Drop a basic form snippet. - Change the field type of any field to 'File Upload'. - Set the `Max # of files` to any value greater than 1 and save the changes. - Attempt to upload more than one file. Observed Issue: Users are unable to upload more than one file. Before this commit: The `Max # of files` option available in the snippet settings had no effect. Even when set to more than one, the file input would only allow replacing the previously uploaded file, preventing users from adding multiple files. After this commit: The `Max # of files` setting now functions as intended. When the limit is set to more than one, users can select multiple files, up to the configured limit and within the maximum file size. If the limit is set to one, users can only upload a single file. task-4626847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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