Wednesday, March 4, 2026
18 changes · saas-18.4
Enhancements to existing features
This update reduces the time and noise involved in running selected automated tests for calendar and point of sale areas. It shares repeated test setup work and suppresses unnecessary test log messages, helping developers validate changes more efficiently without affecting normal business workflows.
Original PR description
- move a bunch of expensive setUp to setUpClass - backport #152378 to avoid password keying in 17.0 also Forward-Port-Of: odoo/odoo#251281 Forward-Port-Of: odoo/odoo#250667
This update adjusts the Romanian tax reporting (l10n_ro_saft) to align with recent changes in the core Enterprise version (CE). The update removes outdated tax codes and adds new ones, ensuring accurate reporting for Romanian businesses. This improves compliance and data accuracy.
Original PR description
Some taxes were no longer needed in CE, so they needed to be removed task-5411745 Forward-Port-Of: odoo/enterprise#108884 Forward-Port-Of: odoo/enterprise#106127
This update streamlines the process of setting up tests for several core Odoo modules, specifically within the accounting and timesheet areas. By centralizing test setup, the team can ensure more consistent and reliable test results, leading to greater confidence in the stability of the system. This change primarily impacts the testing process, not the functionality itself.
Original PR description
Forward-Port-Of: odoo/enterprise#109111 Forward-Port-Of: odoo/enterprise#108739
Resolved issues and error corrections
This fixes an issue where removing a product from a pricelist rule could leave inconsistent rule data behind. Pricelist rules now reset to a global application when the linked product template is removed, helping prevent corrupted pricing configuration.
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#250531 Forward-Port-Of: odoo/odoo#249417
The Danish demo company now includes a street number in its sample address. This supports Nemhandel requirements and helps demo or test data better match expected Danish e-invoicing address details.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
The time off calendar test flow was adjusted to avoid occasional failures during automated validation. This helps keep releases moving smoothly by reducing false alarms in quality checks, without changing how employees use the time off calendar.
Original PR description
This fix adjusts the tour in `test_hours_time_off_request_calendar_view` as it was failing in some cases. runbot error 237682 Forward-Port-Of: odoo/odoo#249267
Italian invoices using Dichiarazione d'intento can now include other applicable 0% taxes on the same line, such as Enasarco and withholding-related taxes. This avoids blocking valid Italian invoicing scenarios and helps businesses issue compliant invoices without manual workarounds.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This fix makes the self-ordering flow choose the intended pickup or service time slot during automated checks. It helps prevent incorrect availability results caused by the time when the test is run, improving confidence that customers see accurate time slot options.
Original PR description
The selected time slot was not the right one as the time of the execution influed on the first choice available. We now specify which time slot to take, and check that this specific timeslot is not available anymore afterwards. runbot-233381 Forward-Port-Of: odoo/odoo#233469
This fixes an internal automated test for Turkey's Nilvera e-invoicing integration so it uses the same invoice preparation flow as the product itself. It helps prevent false test failures and reduces the risk of future invoice-sending errors caused by missing data fields.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task Forward-Port-Of: odoo/odoo#232105
The mail app now ignores archived blacklist entries when checking whether a user is blacklisted. This prevents outdated or disabled blacklist records from incorrectly blocking valid email-related actions, improving reliability for affected users.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
Clicking More options in the HTML editor now keeps the editor active instead of moving focus to the button. The command list also filters correctly as users type, making it easier to find formatting options without interruption.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#249352 Forward-Port-Of: odoo/odoo#244454
This update ensures self-order transactions in the Odoo Enterprise system now adhere to the same data validation rules as standard point-of-sale orders. This enhances data accuracy and reliability, reducing potential errors and improving the overall transaction process. It addresses a previous issue related to inconsistent validation.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/enterprise#109167 Forward-Port-Of: odoo/enterprise#108538
This update resolves a problem with the generation of CSV reports for Peru-specific accounting modules. The issue stemmed from incompatible CSV formatting settings within the Odoo system, specifically related to Python 3.13. The fix ensures reports are generated correctly and efficiently.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a key configuration element within Studio's interface, ensuring proper functionality and report customization. It also addresses a previous issue with table menu positioning within Studio.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724
This update ensures that Website Studio's translation features only apply to views within the Website module, preventing incorrect translations from other websites. The change corrects a bug where the default language of the first website was being used, improving the accuracy of translations within the Studio interface. This ensures a more reliable and consistent experience for users working with Website content.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#108199 Forward-Port-Of: odoo/enterprise#107459
This update corrects a display issue where upsell sales orders created from subscriptions incorrectly showed as 'Quotation' in their preview. The fix ensures that upsell orders now match the naming convention of standard sales orders, providing a more accurate and consistent user experience. This improves clarity and reduces confusion for users managing subscription-based sales.
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#109268
Forward-Port-Of: odoo/enterprise#106767This update ensures that product weights sent to the Sendcloud shipping API are always at least 0.001. Previously, the API rejected shipments with weights below this minimum threshold. This change prevents shipping errors and ensures accurate delivery calculations with Sendcloud.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update fixes an issue where negative values were appearing in tax reports for carried over amounts (specifically lines 81-88). The change ensures that tax report XML files generated accurately reflect tax calculations, preventing potential reporting discrepancies. This improves the reliability of tax reporting.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109389 Forward-Port-Of: odoo/enterprise#108916