Monday, September 14, 2026
8 changes · saas-19.2
Resolved issues and error corrections
This fix makes an automated rental shop checkout test wait until the calendar has fully updated before choosing a rental date. It helps prevent false test failures, supporting more stable quality checks without changing customer-facing behavior.
Original PR description
The shop_buy_rental_stock_product tour can select a day from the previous month's grid before the date picker finishes rendering the next month. This can leave the rental period unchanged and cause the cart price assertion to fail. Wait for an animation frame after clicking "next month" before selecting a day. runbot-240903
The Australian payroll onboarding flow now correctly accepts bank details when a BSB and bank name are provided, even if the BIC field is empty. This prevents an incorrect warning from blocking or confusing users during payroll setup.
Original PR description
Bug reproduction: 1 - Install l10n_au_hr_payroll_api, settings→payroll→AU localization 2 - Start payroll onboarding `2.1 - Next step→fill in BSB and keep BIC empty→Set Bank details` 3 - No BSB or bank set warning continues to appear Bug cause: 1 - For that warning, there is check that checks bic (to not keep empty) Bug solution: 1 - bic check is removed and bank name check is added task-6540863
The “Insert in Spreadsheet” dialog no longer shows an unwanted horizontal scrollbar or duplicate scrolling on small screens. This keeps the spreadsheet selection experience cleaner and easier to use without changing business workflows.
Original PR description
Opening "Insert in Spreadsheet" displayed an unwanted horizontal scrollbar in the spreadsheet selector. On small viewports, it could also produce a second scrollbar alongside the scrollable modal. The selector reused the `o-spreadsheet-templates-dialog` class, whose styles belong to `documents_spreadsheet`. This applied template-only max-height and overflow rules to the selector and made `spreadsheet_edition` rely on styles from a dependent module. Give selector dialogs their own class and keep the template-specific styles on the template dialog. Move the shared pager layout to `spreadsheet_edition` under a dedicated class, and update both pager consumers and the dashboard document selector. Task: 6526781 Forward-Port-Of: odoo/enterprise#130897 Forward-Port-Of: odoo/enterprise#130114
The Time Off approval options were renamed so they match the approver labels shown on employee records. This reduces confusion by making it clearer that requests using the HR-based approval route notify the HR Responsible person, not the separate Time Off approver.
Original PR description
## Issue Currently, the different options for the approval of a time off (allocation) request are the following: 1. None needed 2. By Time Off Officer 3. By Employee's Approver 4. By Employee's…
## Issue
Currently, the different options for the approval of a time off (allocation) request are the following:
1. None needed
2. By Time Off Officer
3. By Employee's Approver
4. By Employee's Approver and Time Off Officer
On the Employee's view form, in the Settings tab, the approvers are named:
1. HR Responsible
2. Time Off
The *By Time Off Officer* option does not notify the *Time Off* approver, but the *HR Responsible*, which is not clear for the users. It would be clearer to use a similar naming convention for both the Approvers on the Employee's form and the options for the approval of the time off (allocation) requests.
<img width="1878" height="592" alt="6535827" src="https://github.com/user-attachments/assets/bc7ad9bb-6b53-4553-8fc8-fb305e7c0b28" />
## Steps to reproduce
1. Install *Time Off* (`hr_holidays`)
2. For an Employee E, set an HR Responsible and a (different) Time Off approvers
3. Create a Time Off request for the Employee E
- Ensure that the selected Time Off Type has its approval method set to "By Time Off Officer"
4. **The user notified off the time off request is the HR Responsible, which is unexpected, considering that we expect an approval from the "Time Off Officer".**
## Justification
In the `_get_responsible_for_approval` method, when using the "By Time Off Officer" option (`'hr'`), it is clearly the `hr_responsible_id` (HR Responsible) who is selected as "responsible" for the approval.
https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave.py#L1557-L1559
The exact same logic is applied for the allocation requests [here](https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave_allocation.py#L1070-L1072).
## Targeted version
We are targeting version 19.2, as it is the version from which the `responsible_ids` field (which was clearly specifying who had to be notified for the approval of a time off request) was removed (see https://github.com/odoo/odoo/commit/d37cf89a6ff134988b4a7c001a97973cd95a2ea8).
If deemed interesting, the same modification can be backported to previous versions too.
opw-6535827This fixes an unstable website editing test by removing an unnecessary language switch and waiting until the Edit button is ready before continuing. It helps prevent false test failures without changing the customer-facing website experience.
Original PR description
In [this commit][1] some steps were added to resolve non-deterministic errors. Just before `...clickOnEditAndWaitEditModeInTranslatedPage(),` three steps were added that switch the language back to parseltongue. This is most likely since the function call implies we are on a translated page. The choice for this function was most likely due to a race condition. As the language was switched to English recently, the edit button might not have time to have switched. To recreate the race condition, remove the step added in this commit but leave the rest of the changes. Run the tour and it will hang up on the first step of `...clickOnEditAndWaitEditMode()` because the Edit button is still in "translation" mode. This commit removes the redundant language change and adds an extra step to check the Edit button is in the correct "mode" before continuing. [1]: https://github.com/odoo/odoo/commit/7f7cc9617381b1a2f61af0875e7b60ab0b7ab3a0 task-5951393
This fixes Nilvera Turkish e-invoices so the amount written in words is fully in Turkish, including the currency subunit such as cents. It prevents mixed-language invoice notes and helps keep foreign-currency e-invoices compliant with local formatting expectations.
Original PR description
### Issue before this commit: When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the…
### Issue before this commit: When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the numbers were correctly translated to Turkish, the currency subunit label was fetched using the customer's language. This resulted in a partially translated string (like "... SIFIR CENTS") instead of the expected fully Turkish text (like "... SIFIR SENT"). ### Steps to reproduce the issue: 1. Download Accounting and l10n_tr_nilvera_einvoice 2. Create an API KEY: https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0#heading=h.e6i8a29lff5t 3. Go to a turkish client on the Accounting tab and click on 'Verify' for the Nilvera status 4. Go to currencies and activate EUR (be sure there is also the translation for currency subunit) 5. Go to invoices, create one for the Turkish customer you already verified setting the currency as EUR and send it with Nilvera 6. See that current output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR CENTS</cbc:Note> (Turkish numbers with English subunit) but the expected output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR SENT</cbc:Note> (Fully Turkish text) ### Cause of the issue: The issue occurs because the currency_subunit_label field is not translated but fetched using the language of the customer in the invoice. ### Reason to introduce the fix: To ensure that the amount in words inside the <cbc:Note> tag is completely formatted in Turkish, complying with Nilvera and local e-invoicing requirements, regardless of the customer language. opw-6523794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287630
The Belgian Codaclean integration now uses the correct CODB naming for payroll documents instead of the older SODA terminology. This reduces confusion for users handling Codaclean payroll files and aligns labels and internal references with the actual document type.
Original PR description
CODB files are the payroll documents that are used for codaclean, they are the equivalent for SODA files from codabox. This pr should rename the files, functions, etc for codaclean so that it is CODB instead of SODA. task-6543478
Product cards using the Chips layout now keep proper spacing when shown in dynamic product snippets outside the shop page. This prevents cramped or collapsed product displays on website pages, improving storefront presentation for visitors.
Original PR description
Steps to reproduce: --- - Install the website_sale module with demo data. - Go to /shop and switch the product layout to Chips. - Exit the editor. - On the home page, open the editor and add the…
Steps to reproduce: --- - Install the website_sale module with demo data. - Go to /shop and switch the product layout to Chips. - Exit the editor. - On the home page, open the editor and add the Dynamic Products snippet. Issue: --- The Products snippet has collapsed card padding when the Chips layout is active. Root cause: --- - The Chips card layout defines `--_padding-base` using `var(--o-wsale-products-grid-gap)` with no fallback value. https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/static/src/scss/product_tile.scss#L632 - When the Products snippet renders outside /shop, the variable is undefined, causing the `calc()` to resolve to a guaranteed-invalid value which collapses the card padding. All other layouts are unaffected because they either do not use `--o-wsale-products-grid-gap` in their padding chain, or already provide a `16px` fallback at the point of use. https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/static/src/scss/product_tile.scss#L407-L410 Solution: --- - 16px matches the default value of `shop_gap` on the website model, ensuring correct padding whenever the variable is not explicitly set. https://github.com/odoo/odoo/blob/4307f657c73a860c755e1499138a878268882f7a/addons/website_sale/models/website.py#L128 ### Before: <img width="1456" height="563" alt="image" src="https://github.com/user-attachments/assets/c28ab183-0af3-4a2a-858d-b85d9995eb07" /> ### After: <img width="1427" height="550" alt="image" src="https://github.com/user-attachments/assets/e0ba80ec-10ad-433f-bf9a-acbaffd56a76" /> opw-6511483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286185