Monday, September 14, 2026
10 changes · saas-19.3
Resolved issues and error corrections
The rental shop test now waits for the calendar to finish updating before choosing a date. This prevents false test failures and helps keep rental pricing checks stable without changing the customer experience.
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 Forward-Port-Of: odoo/enterprise#130822
The Navarra SII tax agency web service link has been updated after the previous address stopped working. This helps ensure Spanish electronic tax reporting for Navarra can continue connecting to the correct service endpoint.
Original PR description
The WSDL URL used for the Navarra tax agency SII web service was no longer working. It has been replaced with the updated endpoint 'ssii_1_1'. task-6457647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285049
This fixes Turkish Nilvera e-invoices so amounts written in words use the correct Turkish currency subunit label, even when the invoice uses a foreign currency such as EUR. It prevents mixed-language invoice notes and helps keep 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#287920 Forward-Port-Of: odoo/odoo#287630
This update removes an unnecessary language switch in a website editor test and waits for the editor button to be ready before continuing. This reduces intermittent test failures, helping keep website editing behavior more reliably validated.
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 Forward-Port-Of: odoo/odoo#286764
This fix ensures the blog post dynamic snippet test opens the website builder in the right mode from the start. It helps prevent intermittent test failures and supports more reliable quality checks for blog editing features.
Original PR description
The blog post dynamic snippet options tour needs debug mode because the dynamic snippet belongs to the Debug snippet group. The tour used to put `debug=1`in the preview iframe path, while the initial website preview client action was opened without debug. This meant `request.session.debug` was only updated once the iframe request was handled. If the snippet template was rendered before that request, QWeb used the empty session debug value and omitted the Debug snippet group. After this commit, we open the preview action directly in edit and debug mode from the Python test instead, so the first server request sets `request.session.debug` before the website builder loads the snippets. Forward-Port-Of: odoo/odoo#283767 Forward-Port-Of: odoo/odoo#281433
Project lists now show the upcoming milestone based on the milestone deadline instead of creation order. This keeps the project overview consistent with the milestone list and helps teams see the correct next deadline at a glance.
Original PR description
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent…
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent with the milestone list. Steps to reproduce: - Create a project with milestones enabled. - Create MS1, then MS2. - Give MS1 a later deadline than MS2. - Open the project list and display the Next Milestone column. Cause: `_compute_next_milestone_id()` aggregated unreached milestones as an `id:recordset` and selected its first element. The ORM orders that aggregate by database ID, so creation order was used instead of the milestone model's deadline order. https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/addons/project/models/project_project.py#L209-L218 https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/odoo/models.py#L364-L377 Solution: Retrieve unreached milestones through their normal ordered search before grouping them per project. This preserves batched computation while ensuring that the selected record follows the established milestone order. opw-6496938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287355 Forward-Port-Of: odoo/odoo#285933
The spreadsheet insertion dialog no longer shows an unnecessary horizontal scrollbar, including on smaller screens. This makes the dialog cleaner and easier to use while keeping spreadsheet template styling separate from the selector layout.
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
Performance appraisals can now be completed without forcing users to fill in a final assessment. This prevents unnecessary blockers when the final assessment is not relevant or not yet available.
Mobile attendance progress bars now keep hour totals on one line and shorten overly long text when needed. This prevents translated labels, such as longer German wording, from spilling over and becoming hard to read.
Original PR description
**Issue** In mobile and in some languages, the text displayed over the progress bar in the attendance app could overflow and be unreadable (e.g. in German: "3h 30Min. / 38h 45Min."). **Fix** The text is kept on a single line and will be truncated at the end if too long. <img width="800" height="841" alt="image" src="https://github.com/user-attachments/assets/3550952d-a83d-48f3-ac99-dcf06ad092bd" /> opw-6501516
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