Tuesday, September 9, 2025
13 changes · saas-18.4
New functionality added to Odoo
The KPI summary now highlights how many documents are waiting in the Inbox and shows the current status of pending tax return types. This gives teams a quicker overview of outstanding document work and compliance deadlines without opening each area separately.
Original PR description
With this commit, `kpi.provider.get_kpi_summary` will show how many documents are present in the Inbox folder, as well as the status of the `account.return.types` (`late`, `longterm`, `to_do`, `to_submit` and `done`) depending on which account.return are not completed and on their due date. Task-id: 5062431 Forward-Port-Of: odoo/enterprise#93720
Enhancements to existing features
The Nilvera integration for Turkish e-invoicing now syncs statuses and PDFs for both E-Invoices and E-Archive documents, including invoices created directly in Nilvera. This helps users see up-to-date invoice results in Odoo, with retrieved PDFs shown in preview and attached automatically for easier record keeping.
Original PR description
[IMP] l10n_tr_nilvera_einvoice: refactor API to include E-Invoices & E-Archive Fixed bugs in API calls triggered during fetch requests and added support for fetching the status of E-Archive files. Updated the action button label to "Sync with Nilvera", which now fetches invoice statuses, retrieves PDFs for both E-Archive and E-Invoices, and includes invoices generated directly in Nilvera, enabling support for additional invoice types currently not supported in Odoo. Invoices/Bills are marked as "Successful" once retrieved. Retrieved PDFs are displayed in the preview and automatically attached to the chatter. The original limit of fetching a maximum of 30 records (status and PDFs) is maintained. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224799 Forward-Port-Of: odoo/odoo#223599
Resolved issues and error corrections
This fixes an issue where visible product tags could disappear from the online shop after migration if the default product variant had no customer-visible tags. Customers can now see the appropriate tags for each variant, improving product information accuracy on the website.
Original PR description
### Steps to Reproduce: 1. Create a database of version 18.0 to 18.3 with the website and website_sale modules installed. 2. Create a product and add some variants for that product. 3. Assign product…
### Steps to Reproduce: 1. Create a database of version 18.0 to 18.3 with the website and website_sale modules installed. 2. Create a product and add some variants for that product. 3. Assign product tags to all variants. 4. In the default variant of the product, add tags where visible_to_customer = False. 5. Migrate that database to version 18.4. ### Issue: After migration, product tags are not shown for any variant If the default product variant has no visible tags. This happens because of the condition: `t-if="any(tag.visible_to_customers for tag in all_product_tags)"` defined in website_sale.product_tags [view](https://github.com/odoo/odoo/blob/saas-18.4/addons/website_sale/views/templates.xml#L2337-L2361) Here, the template is always rendered with all_product_tags from the [default variant](https://github.com/odoo/odoo/blob/saas18.4/addons/website_sale/views/templates.xml#L1979-L1987). So, if the default variant has no visible_to_customer tags, the condition fails, and as a result, tags from other variants are never displayed—even if they are visible. ### Fix: Remove the redundant outer condition: `t-if="any(tag.visible_to_customers for tag in all_product_tags)"` Since inside the loop we already have: `<t t-if="tag.visible_to_customers">` which checks visibility for each tag individually across variants, There’s no need for the extra wrapper condition. This ensures product tags are displayed correctly for all variants that have visible_to_customers = True, regardless of the default variant’s tags. OPW - [5031068](https://www.odoo.com/odoo/project/70/tasks/5031068) UPG - [3114696](https://upgrade.odoo.com/odoo/upgrade.request/3114696) Description of the issue/feature this PR addresses: #### Current behavior before PR: The product tag is not visible on the website, even though the tag is visible to customer <img width="700" height="500" alt="image" src="https://github.com/user-attachments/assets/64bea4b4-314a-4595-8b46-b93b745086b0" /> #### behavior after PR is merged: The product tag is visible now <img width="700" height="500" alt="image" src="https://github.com/user-attachments/assets/694cc0c8-fc92-441c-b7be-e835298fbec2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
TicketBAI submissions could fail when a point of sale name created an invoice series longer than Spain's required 20-character limit. The system now shortens that value before submission, preventing a confusing upload error and helping affected POS orders send successfully.
Original PR description
Before this commit, records with sequences over 20 characters will present a cryptic error when uploaded to TicketBAI. Steps to reproduce ----- 1. Create a point of sale with a name >20 characters 2. Validate an order on the POS 3. Go to Point of Sale > Orders > Your order, click "Send to TicketBAI" 4. Invalid Operation ``` 002: Fichero no cumple el esquema XSD. Detalle del error: cvc-maxLength-valid: Value 'ThisisaveryveryveryveryverylongPOSnameTEST' with length = '42' is not facet-valid with respect to maxLength '20' for type 'TextMax20Type'. ``` Issue ----- The schema for SerieFactura specifies a TextMax20Type, but the generated sequence can be over 20 characters. Solution ----- Truncate the sequence to 20 characters. opw-4750372 Forward-Port-Of: odoo/odoo#225776 Forward-Port-Of: odoo/odoo#225436
Online product pages now update the displayed price when shoppers change the quantity to meet a pricelist discount threshold. This helps customers see the correct discounted price before adding items to their cart, reducing confusion and pricing mismatches.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a pricelist with a discount based on a min quantity; 2. have the pricelist available in eCommerce; 3. open a product page where the discount can get applied; 4. change the quantity in the selector to the minimum for the discount. Issue ----- The product's price doesn't get updated to show the discount. Cause ----- The `_onChangeAddQuantity` function, which is supposed to update the price, is applied to the `form .js_product:first [name="add_qty"]` selector, but as of saas-18.4, the `form` element is located inside of the `.js_product` element, making it no longer work. Solution -------- Change the selector to `.js_product:first form [name="add_qty"]`. opw-5037669
Fixes a website builder error that could appear when users removed a parallax effect from a background image inside another image-backed section. This makes editing nested website elements more reliable and prevents disruptive traceback popups during page design.
Original PR description
Before this commit, setting parallax to "none" for elements nested inside other elements with a background image caused an error. The issue occurred because the function `showMainColorPicker` was…
Before this commit, setting parallax to "none" for elements nested inside other elements with a background image caused an error. The issue occurred because the function `showMainColorPicker` was called after the `.parallax` span element was removed. Since the `.parallax` element is the editingElement of this option, the function should not have been invoked in the first place. This commit fixes the issue by querying the editing element only once during the setup of `BackgroundImageOption`. This ensures that even if `showMainColorPicker` is called after the `.parallax` element is removed, no error occurs. How to reproduce The problem can be reproduced with many combinations of nested elements. For example: 1. Place the `s_three_columns` snippet 2. Set a background image for the whole snippet 3. Set a background image for a single card 4. Set a parallax effect for the card background image (e.g.: "Scroll Effect" -> "Fixed") 5. Set the same parallax effect back to "none" (Scroll Effect -> "None") 6. Traceback pops up task-4367641
Vendor bill printouts in Chile now use the standard report layout unless they are specific electronic purchase invoices. This prevents company and customer details from appearing swapped, making printed bills clearer and more accurate for accounting teams.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type…
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type Purchase and enable Use Documents. 5. Go to Accounting > Vendors > Bills and create a bill. 6. Print Invoices / Invoices without payments. issue: ------ The customer and company data are swapped (interchanged), and It is wrong from vendor bills point of view. solution: --------- The l10n_cl reports layout should only be applied to: - out_invoice or out_refund - or when l10n_latam_document_type_id = (46) Electronic Purchase Invoice **Before:** <img width="762" height="425" alt="image" src="https://github.com/user-attachments/assets/e042485b-5d82-455f-9f34-03a0a9cdf5cc" /> **After:** <img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/c5d09e58-bcf0-48ab-a0ae-0e37c0473a67" /> opw-4937097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224454
This fixes an error that could block users from sending a credit note after recording a partial payment. Businesses using electronic invoicing can now complete this workflow without encountering a system traceback.
Original PR description
When User sends the partially paid credit note, A traceback will appear. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data and switch to CO Company - Create a Credit note > Confirm > Register a partial payment > Send > Send Traceback: ``ValueError: The following child node is not defined in the template: CreditNote/cac:PrepaidPayment`` https://github.com/odoo/odoo/blob/7136383f47f3f86bc803efaa3837f4879b211b11/addons/account_edi_ubl_cii/tools/ubl_21_credit_note.py#L26 Here, ``cac:PrepaidPayment`` node is missing in the CreditNote. So, It will raise the above traceback when sending the credit note. sentry-6814211355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223527
Fixes an issue where extra hours time off could be approved after refusal without deducting the used duration. This ensures employee time off balances remain accurate and prevents repeated use of the same extra hours.
Original PR description
Steps to reproduce: - On the time off dashboard, create a new leave with the type "Extra hours" - Click on the request again, refuse the request - Click on the request, and now approve the time off -If you now try to create a new time off with the type "Extra hours", you'll notice that the duration of the previously "refused then approved" time off is not taken into account Reason: The action tied to the "Approve" button was wrongly named in the inherited hr_leave model of the hr_holidays_attendance module, which prevented the computation for the approval to be taken into account. How it was fixed: Correcting the name allowed the function to be called properly and the calculation is now performed correctly. Task ID: 5051271 Forward-Port-Of: odoo/odoo#225623 Forward-Port-Of: odoo/odoo#224992
German tax report XML exports now keep periods as decimal separators, matching ELSTER's current import requirements. This prevents VAT return amounts from being ignored during submission due to invalid number formatting.
Original PR description
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax…
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax Report*. 5. Export the report to XML from gear icon. **Observed behavior:** - The generated XML contains amounts with a comma `,` as the decimal separator. - Elster ignores values with commas, so amounts are missing from the submitted VAT return. **Root cause:** - The QWeb XML export replaced the decimal point `.` with a comma `,`. - Elster launched a new tax return application (*einfachELSTERplus*), which enforces `.` as the decimal separator. **Solution:** - Stop replacing `.` with `,` when exporting values to XML. - Keep amounts as floats with period separators, while still rounding or inverting values as required for specific Kz fields. **ref:** https://www.elster.de/eportal/helpGlobal?themaGlobal=osseust_import opw-4935738 Forward-Port-Of: odoo/enterprise#94130 Forward-Port-Of: odoo/enterprise#93623
Portal users who are invited to edit a Knowledge article no longer see controls for publishing the article publicly or changing other members' access rights. This prevents confusing permission errors and keeps article sharing options aligned with the user's actual privileges.
Original PR description
Steps to reproduce =============== As an admin ---------------- 1. Go to knowledge 2. Open any article. 3. Add a portal user as a member with write access. As a portal user -------------------- 1. Open the shared article. 2. On the top right corner, click on members button --> List of members along with their rights will be shown. The portal user can open the dropdown to alter the rights of other members. Though doing so will raise an AccessError (in the logs). After this commit, the portal user will *no* longer see the 1. Toggle to share article to the web. 2. Dropdown to modify members' rights. Task-4863456 Forward-Port-Of: odoo/enterprise#89394
Fixed an issue where subscription payments made through the portal could create and send the same invoice twice when automatic invoicing was enabled. This prevents duplicate EDI-signed invoice documents and reduces customer confusion and accounting cleanup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Use a localization that uses EDI-signed invoices; 2. enable `sale.automatic_invoice` via `ir.config_parameter`; 3. pay for a subscription via the portal. Issue ----- Invoice is generated twice. Cause ----- Commit 7c5fd63729c1 added automatic EDI invoice signing for subscriptions paid via portal. This assumed that the `sale.automatic_invoice` parameter remained unset. If this parameter is set, the invoice is already generated when post-processing a transaction in `sale`. Solution -------- Don't send invoices whose `is_move_sent` field is set to `True`. Also, don't set `from_cron` to `True` on automatic payments, as this is only intended for moves that have `sending_data` filled by `account.move.send.batch.wizard`. opw-4648189 Forward-Port-Of: odoo/enterprise#93881
Fixed an issue where changing a website form to send outgoing emails could trigger an error when visitors submitted it. The form now refreshes correctly after the model change, ensuring required hidden fields are added and submissions work as expected.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. -…
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. - click the form and in actions select the `more models`, and select `outgoing mails(mail.mail)` model and `save`. - `Submit` the form, and the error appears in the `logs`. **Error:** `KeyError: 'website_form_signature'` **Cause:** This error occurs when submitting the "Send Email" form from the website. By default, the form action is `"Send an E-mail"`, and when the user `changes` the form’s model to outgoing mails (mail.mail), which also has the action "Send an E-mail," the system checks the existing model [1] and retrieves it. Since `shouldRerender` is set to false, [2] is not executed, and as a result, the `email_to(hidden field)` is not present in the form. And the website_form_signature is added from [3], but due to the condition at [4], the code at [3] is not executed. When it is accessed at [5], KeyError is raised. **Fix:** This commit ensures that when the user changes the model, `rerenderXml` is executed so that the `hidden field` is also added. [1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156 [2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 sentry-6746753251 Forward-Port-Of: odoo/enterprise#93287