Wednesday, May 27, 2026
13 changes · saas-18.4
Resolved issues and error corrections
This fixes an issue where the website editor could become inconsistent after a save was blocked, such as when a required product name was missing. Users can now continue editing normally after the error message, avoiding ignored keystrokes and repeated correction attempts.
Original PR description
When a save fails (for example due to a required field), the editor stays open, but some transient editor classes may already have been removed from the DOM.
This leaves the editor in an inconsistent state and can trigger a weird flow while making changes.
For example, as a result, users may see every second keystroke ignored after a failed save.
Steps to reproduce:
- Open a product page in website editor
- Remove the product name
- Click save
- The expected popover is shown ("Operation cannot be completed")
- Type again in the product name field => Every second keystroke is ignored (rollbacked actually).
task-5190459
Forward-Port-Of: odoo/odoo#263568This fix stops delivery orders for serial-tracked products from being completed when the serial numbers have been removed but a quantity remains entered. It keeps the delivered quantity aligned with the recorded serial numbers, helping prevent inventory traceability gaps.
Original PR description
Writing both `quantity` and `lot_ids` on a tracked move in the same form save leaves `move.quantity` stored at the user value while `_set_lot_ids` unlinks the remaining move line; the picking can then be validated to 'done' with no serial recorded. Force `_compute_quantity` at the end of `_set_lot_ids` so the stored value stays in sync with the move lines. Steps to reproduce: - Serial-tracked product, 6 in stock - Create a delivery order for 6 units of that product - In the delivery form, on the move row: type "1" in Quantity and remove all 6 lots from the Serial Numbers widget. - Save, Validate Before: picking goes to Done with quantity=1 and no serial. After: clear UserError, quantity stays in sync with mls. opw-6192841 Forward-Port-Of: odoo/odoo#266394
This fix prevents regular Live Chat users from seeing or selecting a chatbot-related filter they do not have permission to access. It avoids an error when opening session filters, keeping the Live Chat sessions screen usable for non-admin staff.
Original PR description
**Steps to Reproduce** 1. Install the **Live Chat** module in version 18.4 or above. 2. Go to: **Settings → Users** * Open your user and change the access rights from **Live Chat / Administrator** to…
**Steps to Reproduce**
1. Install the **Live Chat** module in version 18.4 or above.
2. Go to: **Settings → Users**
* Open your user and change the access rights from **Live Chat / Administrator** to **Live Chat / User**.
* Alternatively, create a new user giving him rights of the **Live Chat / User** group.
3. Login using the Live Chat user.
4. Open the **Live Chat** application and navigate to: **Live Chat → Sessions**
5. Open any existing session. The session and its messages are accessible without any issue.
6. In the search bar, click: **Filters → Custom Filter**
7. Select the field `Chatbot Messages (chatbot_message_ids)`. You will face the below traceback.
**Issue Description:**
The issue happens because `discuss.channel` records are accessible to users having the `im_livechat_group_user` group through the Sessions menu: https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/views/im_livechat_channel_views.xml#L310-L315
The field `chatbot_message_ids` is defined as:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/models/discuss_channel.py#L165
This field points to the `chatbot.message` model, but access to that model is restricted to `im_livechat_group_manager` only:
https://github.com/odoo/odoo/blob/459a775a066fe1465e53fc751045baed39f80118/addons/im_livechat/security/ir.model.access.csv#L15
As a result, when a Live Chat user tries to use `chatbot_message_ids` in a custom filter, Odoo attempts to read `chatbot.message` records and raises an `AccessError`.
This issue started happening after the access rights changes introduced in pr : https://github.com/odoo/odoo/pull/201880
Specifically, the following ACL changes:
https://github.com/odoo/odoo/pull/201880/changes#diff-c1592d633a34db44a7cc2a527482cecc56127cbba72649e7318dcf63ccf477afR19-R20
**Solution:**
To fix this issue, added the group `im_livechat_group_manager` on the field `chatbot_message_ids` so only those user can access the field who belong to the group.
**Traceback:**
```.py
odoo.exceptions.AccessError: You are not allowed to access
'Chatbot Message' (chatbot.message) records.
This operation is allowed for the following groups:
- Live Chat/Administrator
Contact your administrator to request access if necessary.
```
opw - [6169395]
upg - [4274573]
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-prThis update brings the spreadsheet component to its latest version and fixes several issues affecting formulas, exported data, range handling, and pivot table cleanup. Business users should see more reliable spreadsheet behavior, especially when exporting data or working with dynamic ranges and pivot formulas.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/62ea2e28fa [REL] 18.4.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/62ea2e28fa [REL] 18.4.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/fc62733c77 [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405) https://github.com/odoo/o-spreadsheet/commit/dc42389b40 [FIX] range: correctly handle unbounded ranges on row/col changes [Task: 6167358](https://www.odoo.com/odoo/2328/tasks/6167358) https://github.com/odoo/o-spreadsheet/commit/403cbb57d0 [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/efe2aa6b2b [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/7eb0e64c77 [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095) https://github.com/odoo/o-spreadsheet/commit/461d411339 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8d2ca9f78c [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fix ensures imported UBL BIS3 invoices correctly calculate the original unit price when a price allowance is provided. Businesses will avoid invoices being created with incorrect line prices in this import scenario.
Original PR description
**PROBLEM** When importing a ubl bis3 file, with only the amount in the AllowanceCharge on PriceAmount it doesn't add the discount to PriceAmount to get the undiscounted price. Which means we create an invoice with the wrong price. This PR fixes that. opw-6102962 Forward-Port-Of: odoo/odoo#258964
This fix stops Danish Nemhandel electronic invoice files from being generated when the customer does not have a VAT number. It helps prevent invalid e-invoicing attempts and reduces processing errors for businesses using Danish localization.
Original PR description
Users with no VAT number shouldn't be able to use Nemhandel and shouldn't have a OIOUBL xml generated. task-6196225 Forward-Port-Of: odoo/odoo#266253 Forward-Port-Of: odoo/odoo#263244
Shop pages now only show product categories that belong to the current website. This prevents shoppers from clicking category links that lead to missing pages, improving browsing consistency on multi-website stores.
Original PR description
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. -…
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. - Open the shop page on website > Click on Desks category. Issue: --- - The Components subcategory is still displayed on Website 1. - Clicking on it leads to a Not Found page since the category is not assigned to that website. Root cause: --- - At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access. - As a result, categories restricted to another website are still shown. Solution: --- - Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed. [1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769 opw-6159549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262410
Payments received through payment providers are now treated consistently as either fully paid or unpaid. This prevents incorrect partial matching on these payments, reducing accounting inconsistencies and reconciliation errors.
Original PR description
When we receive a payment from a provider, we allow partial reconciliations to be done on this move, but we shouldn't. Payments coming from providers are always either fully paid, or not paid at all. task-5893189 Forward-Port-Of: odoo/odoo#254597
Invoice PDFs printed before being sent now correctly show the Proforma header, matching the on-screen preview. After the invoice is sent to the customer, printed PDFs use the normal invoice header, reducing confusion and ensuring customers receive the right document status.
Original PR description
***Steps to reproduce*:** - Create and confirm an invoice. - Open the invoice preview and use the Print option to generate the PDF. - Send the invoice to the customer. ***Observed behavior*:** - In…
***Steps to reproduce*:** - Create and confirm an invoice. - Open the invoice preview and use the Print option to generate the PDF. - Send the invoice to the customer. ***Observed behavior*:** - In the preview, the header is displayed as *Proforma*. - Before sending the invoice, the downloaded PDF from the Print option does not contain the *Proforma* header. - After sending the invoice, the preview correctly no longer shows the *Proforma* header, but the Print PDF output also continues without the expected behavior. ***Cause*:** - The *Proforma* header should be displayed when a confirmed invoice has not yet been sent to the customer. - Once the invoice is sent, the document should display the normal invoice header instead. - The PDF generation flow from `action_print_pdf` did not correctly pass the proforma context based on whether the invoice had already been sent. ***Fix*:** - Update the functional logic in `action_print_pdf` to use: `with_context(proforma_invoice=not self.invoice_pdf_report_id)` - This ensures that invoices not yet sent to the customer are generated as *Proforma* invoices. - Once the invoice has been sent, the PDF is generated with the normal invoice header instead. opw-6169132 Forward-Port-Of: odoo/odoo#265825
This fix makes EU VAT validation updates more reliable by preventing timing conflicts when retrieving validation identifiers and waiting for updates. It also improves clarity around validation status changes and adds test coverage to help avoid regressions.
Original PR description
- Avoid race condition while getting the IAP VIES identifiers - Clarify to which state the Intra-Community value has been updated - Increment validity of the webhook_token while waiting for a push update - Add more tests, especially for the controller and the cron - Remove no-longer-relevant tests task-none Forward-Port-Of: odoo/odoo#266228 Forward-Port-Of: odoo/odoo#260440
This fixes an issue where filtering records by a numeric custom property could return too many results. Users will now see only the records matching the selected property value, improving accuracy in searches and reports that rely on these filters.
Original PR description
# How to reproduce - Go to the Form view of a model to which you can Add Properties (e.g. Project > Tasks) - Click on the gear icon > Add Properties - Create a property field with : - Name : X -…
# How to reproduce
- Go to the Form view of a model to which you can Add Properties
(e.g. Project > Tasks)
- Click on the gear icon > Add Properties
- Create a property field with :
- Name : X
- Field Type : Decimal
- Create two records for that model and set the value of the property to 1 & 2
- Go back and Add a custom filter with ('Properties.X', '=', 1)
# The problem
We see both records even tho we should only see one
# Cause of the issue
When doing the search, we transform the domain into the where clause of a
query. This transformation is done with the `condition_to_sql()`
function of the concerned field (`fields_properties` in our case):
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L589
In this function, we manipulate a bit the condition depending on the value,
notably if the value is/contains True. To check it does, we do this :
https://github.com/odoo/odoo/blob/ba9e18688cc9c6e0d4da5ab60acf08d4c49b99d7/odoo/orm/fields_properties.py#L601
The issue is that in python, True in [1] and evaluates to True
because bool is a subset of int. This changes the condition and replaces it in
our case with ('Properties.X', '!=', 'False'), which is obviously not what
was initially asked for.
opw-6224811
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265835Fixes an issue where payments made from a sales order payment link could lose their connection to an invoice if the invoice was manually created while the payment was still processing. This helps ensure completed payments are automatically matched with the right invoice, reducing reconciliation errors and manual follow-up.
Original PR description
Steps to reproduce: - Ensure Automatic Invoice setting is on - Create sales order for product with ordered quantites invoicing policy - Generate a Payment Link - Pay with the ACH Direct Debit method via a provider (e.g. Stripe) - While the payment is processing, confirm the sales order, create an invoice, confirm the invoice Current Behavior: When the payment is finished processing, the payment is not automatically linked to the corresponding invoice Expected Behavior: When the payment is finished processing, the payment should be linked to the invoice despite it being created by a user Explanation: The payment transaction's link to invoice_id is severed in PaymentTransaction._invoice_sale_orders if an invoice is created before the payment is cleared. This will eventually lead to the account.payment created automatically later on not being reconciled with the invoice. opw-6087656 Forward-Port-Of: odoo/odoo#264800
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with many sales orders. The fix ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and installation failures.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118203 Forward-Port-Of: odoo/enterprise#118008