Wednesday, March 4, 2026
18 changes · saas-18.3
Enhancements to existing features
This update streamlines test execution by consolidating repetitive setup steps into a single location, reducing the time and resources needed to run tests. By avoiding redundant object creation, the changes improve test performance and overall system stability. This primarily impacts the Google Calendar and Microsoft Calendar modules.
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#251045 Forward-Port-Of: odoo/odoo#250667
This update streamlines the process of setting up tests for several core Odoo modules, specifically within the timesheet and payroll areas. By centralizing test setup, the team has improved the efficiency and reliability of our automated testing, leading to faster identification and resolution of potential issues.
Original PR description
Forward-Port-Of: odoo/enterprise#108971 Forward-Port-Of: odoo/enterprise#108739
Resolved issues and error corrections
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even after the conversation had already ended. Now, the warning only appears when a chatbot conversation is actively in progress, creating a smoother and less disruptive user experience for customers interacting with the chatbot.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251335 Forward-Port-Of: odoo/odoo#247918
This update fixes a minor issue where the dynamic snippet carousel wasn't displaying correctly when showing a small number of items. The fix ensures a smoother, more consistent scrolling experience, especially with limited product data. It optimizes how the carousel handles data presentation for better performance.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding).
This update fixes a potential issue where VIES validation errors caused errors in Odoo, specifically impacting OCR invoice processing. By catching a broader range of exceptions from the VIES service, the system is now more resilient to invalid XML responses and prevents errors from propagating.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#249853
This update expands the color field options within the Odoo Gantt editor, allowing users to select all integer fields for color customization. Previously, the color field was limited to fields already present in the view. This change provides greater flexibility for visualizing project timelines and tasks.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029
This update adds the street number to the demo company data for Denmark (l10n_dk). This is necessary to ensure accurate reporting and integration with nemhandel, a key payment processing system, improving the demo data's realism and usefulness for testing and demonstration.
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
This update fixes an issue where credit notes incorrectly rounded prices, leading to discrepancies in accounting. The change ensures that credit notes accurately reflect the original purchase price, regardless of rounding settings. This improves financial accuracy and reduces potential errors.
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#249894 Forward-Port-Of: odoo/odoo#247617
This update resolves an issue preventing multiple tax lines (like Enasarco and RIT) from being added to Italian invoices within the Odoo system. Previously, only the DOI tax could be listed on a single line. This change aligns with Italian tax regulations, allowing for more accurate invoice processing and reporting.
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
A test failure related to invoice data formatting was resolved. The update ensures the correct data structure is used when generating electronic invoices, preventing potential errors and improving the reliability of the export process. This fix addresses a technical issue that could have impacted invoice generation.
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
This change ensures that the Website Studio XML editor only uses translated views for websites, preventing incorrect translations from being displayed. The update modifies how the Studio editor retrieves related views, specifically targeting the Website module to improve the user experience and avoid unintended translation behavior.
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. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. 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/odoo#249938 Forward-Port-Of: odoo/odoo#237000
This update ensures that the Website Studio XML editor correctly uses translations only for the specific website being edited. Previously, it incorrectly defaulted to translations for the first website in the database, leading to potential inconsistencies. This fix improves the accuracy of translations within the Studio environment.
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 ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email restrictions. This change improves the accuracy of email delivery and prevents potential issues for users who have been deactivated. The fix was originally reported and addressed in a previous pull request.
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
This update corrects a display issue where upsell sale orders created from subscriptions were incorrectly labeled as "Quotation". The fix ensures that upsell orders now display as standard sales orders, aligning with the naming convention for initial subscriptions. This improves clarity and consistency for users.
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 resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for Early Payment Discounts (EPD) within this format, ensuring accurate invoice generation for businesses using this standard. This improves compliance and reporting accuracy.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251736 Forward-Port-Of: odoo/odoo#244659
This update ensures that product weights sent to the Sendcloud shipping API are always at least 0.001. Previously, the API required a minimum weight of 0.00099, which caused issues with certain products. This change ensures accurate shipping calculations and data transmission to 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 tax reports were generating negative values for carried over tax lines (81-88). The change ensures that the XML output accurately reflects tax calculations, preventing potential errors in reporting and compliance. This improves the reliability of tax reports.
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
This update corrects a previous error that prevented users from sending follow-up reports by post when they lacked sufficient permissions to modify company settings. The fix allows for report sending by automatically granting necessary access, ensuring reports can be generated without interruption. This resolves a potential roadblock in the reporting process.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855 Forward-Port-Of: odoo/odoo#248677