Monday, September 22, 2025
9 changes · saas-18.4
Enhancements to existing features
Australian payroll withholding calculations for study and training support loans have been updated to align with the latest ATO Schedule 8 guidance. This helps employers apply the correct PAYG withholding rates for affected payslips from the required effective date.
Original PR description
This commit updates the Schedule 8 witholding flow and rate for mid year update as per ATO guidelines effective from 24-09-2024. https://softwaredevelopers.ato.gov.au/2025-pay-you-go-payg-withholding-tax-tables Task: 5088270 Forward-Port-Of: odoo/enterprise#95083
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#225476This 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
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
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
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
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