Tuesday, March 3, 2026
11 changes · saas-18.2
Enhancements to existing features
The pull request improves the wording and references used by internal translation lint checks. This helps developers understand why certain translation rules exist and how to resolve issues more consistently, with no direct impact on end users.
Original PR description
- Update documentation link for E8502. - Clarify why E8505 is in place and give an example. Forward-Port-Of: odoo/odoo#251444
Resolved issues and error corrections
This fix prevents Chilean miscellaneous journal entries from being blocked by a document-number validation that does not apply to them. Businesses can now reset, rename, and save these accounting entries without an incorrect error, while validation remains in place for actual electronic documents.
Original PR description
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL…
Currently, editing a posted `miscellaneous` journal entry in Chile localization incorrectly raises a validation error. **Steps to reproduce:** - Install the `l10n_cl` module and switch to the `CL company`. - Go to Accounting > Accounting > Journal Entries. - Create a balanced entry using the `Miscellaneous journal `and `post` it. - Reset it to draft, modify the `name`, and try to `save` it. **Observation:** `Validation error`: `The DTE document number (folio) must contain only digits.` **Root cause:** At [1], the constraint validation is applied to all journal entries in Chilean companies, including `miscellaneous` journals. However, `miscellaneous journals (move_type = 'entry')` are not linked to Chilean electronic documents, so the numeric folio validation should not apply to them. **Fix:** This commit ensures that the validation is not raised for `miscellaneous` journal types by excluding miscellaneous journals from the numeric folio validation constraint. [1]: https://github.com/odoo/odoo/blob/f39785bcddd1eb5b7fb503d053c9bb66e2a0f15c/addons/l10n_cl/models/account_move.py#L20-L30 opw-5926773 Forward-Port-Of: odoo/odoo#248965
This fix prevents pricelist rules from keeping an invalid product-variant setting after the linked product is removed. It automatically resets the rule to apply globally, avoiding corrupted pricing data and confusing pricelist behavior.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249417
The Hungarian tax audit export now avoids accidentally saving invoice chain updates while generating audit data. This prevents unintended changes to invoice records and helps keep accounting data consistent after an export.
Original PR description
At the moment, the Hungarian tax audit export wizard's `action_export` creates a savepoint with `flush=False`. The intention of this savepoint is to roll back the changes to `l10n_hu_edi_invoice_chain` once the savepoint exits. But because the changes to `l10n_hu_edi_invoice_chain` stay in cache, and the cache is not flushed before the savepoint is created nor cleared afterwards, those changes end up being committed to DB. Which is precisely what the savepoint was there to prevent. Solution: we use `flush=True` to make sure the cache is flushed before and cleared after the savepoint. task-none Forward-Port-Of: odoo/odoo#251322 Forward-Port-Of: odoo/odoo#250971
Closing the email composer after selecting more than 500 CRM leads no longer triggers an error. The composer now uses the selected records from the page context when its stored recipient list is unavailable, helping users complete bulk email workflows without interruption.
Original PR description
Steps to reproduce: 1. Install `crm` 2. Create leads more than 500. 3. Select all and try to send email 4. Not close the wizard by "X" Issue: - Traceback occurs: `Uncaught Promise > Unexpected end of JSON input` Cause: - res_ids is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of `active_ids` exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails while dismissing the wizard at `onCloseWizardModal` Solution: - Fallback to context.active_ids when res_ids is not available opw-5891862
This fix ensures a bank account trust check is performed on a single record at a time, preventing incorrect behavior when multiple records are involved. It improves reliability in accounting-related payment and bank account workflows without changing the user experience.
Original PR description
In some cases, the check was done on multiple records, though the method should be called on one and only one record. Forward-Port-Of: odoo/odoo#251589 Forward-Port-Of: odoo/odoo#251457
Credit notes for card-paid Point of Sale orders now keep the original amount when cash-only rounding is enabled. This prevents small incorrect rounding adjustments on refunds and keeps accounting totals consistent with the original sale.
Original PR description
**Steps to reproduce:** - Setup a rounding of 0.05 - Add it to the PoS settings, turn on the only for cash setting - Make a purchase for 13.01, pay by card - Go to the backend, we have the correct price of 13.01 - Revert the invoice by making a credit note - The price is only 13.00 and we have a rounding of -0.01 **Why the fix:** When making a credit note, we round the price if we find a rounding method, not taking the **only_round_cash_method** setting into account. After this commit, we now check if the reversed entry (the invoice) has a rounding line. If it does not, we skip the rounding. If a rounding is found on the reversed entry, we still round the current account move. opw-5871514 Forward-Port-Of: odoo/odoo#247617
This update fixes a minor inconsistency in the Documents app by ensuring action names (like 'Vendor Bills') accurately reflect the type of account move being created, regardless of the document selected. This improves clarity and usability for users creating account moves from the Documents app.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109180
This update resolves an issue where payslip line creation was failing in the stable version of Odoo Enterprise. The team re-introduced a previous fix to ensure stable operation and prevent errors related to missing data fields. This improves the reliability of payroll processing.
Original PR description
Related is not applied correctly in stable after https://github.com/odoo/enterprise/pull/108729, leading to a missing field error, we reintroduce it for stability reasons Forward-Port-Of: odoo/enterprise#109198
This update corrects a display issue where upsell sales orders created from subscriptions incorrectly showed as "Quotation" instead of a standard sales order. The fix ensures that upsell orders now match the naming convention of other sales orders, providing a more consistent and accurate view for users. This improves clarity and simplifies reporting.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#106767This update corrects a reporting issue related to Swiss payroll transmissions. Specifically, it now displays a warning instead of an error when the AVS (authorized verification system) value is negative, ensuring accurate reporting and avoiding potential disruptions to payroll processing. This change improves the reliability of financial data for Swiss businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#109046