Monday, March 23, 2026
22 changes · saas-18.3
Resolved issues and error corrections
This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it dynamically adjusts to the dark mode theme using a standard muted data color, ensuring a consistent and professional appearance across all viewing modes.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111353 Forward-Port-Of: odoo/enterprise#110108
This update corrects a map data issue where Russia was missing from the Asia map. It also includes a new map for Oceania, ensuring more accurate geographic representation. This improves the visual accuracy of location-based data within Odoo.
Original PR description
- Fix Asia map (russia was missing) - Added Oceania map Task-5224009 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-pr Forward-Port-Of: odoo/odoo#248847
This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports that rely on geographic visualizations. This update primarily impacts the spreadsheet functionality.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009 Forward-Port-Of: odoo/enterprise#107912
This update addresses a technical issue related to the validation of partner country information within the l10n_ec_edi module. The fix ensures that the identification type of a partner aligns with their registered country, resolving two failing tests. This improves the accuracy of EDI processing for Ecuadorian businesses.
Original PR description
In pr https://github.com/odoo/odoo/pull/248585 I added a check that verify if the l10n_latam_identification_type of a partner correspond to the partner country. It breaks two tests which are fixed here. opw-5801824
This update resolves an issue preventing invoices to Åland Island (AX) partners from being correctly sent via PEPPOL. Previously, invoices were generated but not transmitted, resulting in attachments but no chatter notifications. This change enables Peppol functionality for companies in Åland Island.
Original PR description
Before this commit, invoice to a partner in Åland Island can't be sent via Peppol. XML and PDF are generated, linked to the account.move, but are not sent and don't appear in the chatter. Steps to reproduce: - Create a partner in Åland Island - Create an invoice - Send to Peppol Current behavior: - Invoice is not sent, appear in the attachment, but doesn't appear in the chatter. Expected behavior: - invoice is sent and attachments are in the chatter This also allow activating Peppol for companies in Åland Island. Ticket [link](https://www.odoo.com/odoo/project.task/5949439) opw-5949439
This update corrects a previous issue that prevented users from finding and adding a partner's bank account when creating a credit note. The system now correctly filters bank accounts based on the expected recipient, ensuring credit notes function as intended. This resolves a limitation that was impacting credit note processing.
Original PR description
Description of the issue this commit addresses: The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field. --- Steps to reproduce: 1. Install account. 2. Create an Invoice to a partner which has a bank account setup. 3. Create a Credit Note for that Invoice. 4. In the "Other Info" tab, remove the partner's bank account. 5. Try to search for his bank account to add it back. It won't show up. --- Desired behavior after this commit is merged: The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move. --- task-5976951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254850 Forward-Port-Of: odoo/odoo#252961
This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures accurate reporting of this payment method, addressing a discrepancy in the Mexican tax invoice generation process. This ensures compliance and accurate financial reporting.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix ensures that a clear error message is always shown when PDF merging fails, regardless of the underlying cause. This improves the user experience and helps identify problems with generated reports.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#211611This update corrects a display issue where the 'Pick Up in Store' option was incorrectly shown for products with excluded tags. The fix ensures that unavailable delivery methods aren't presented to customers, improving the user experience and maintaining consistent behavior across the website.
Original PR description
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page. Steps to produce: --- - Install…
Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.
Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
- In the `Stores` tab, set your company warehouse.
- In the `Availability` tab, add the created tag to Excluded Tags.
- Publish the delivery method.
- Open the tagged product on the website.
Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.
Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.
Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
for that delivery method. This keeps the behavior consistent across
the website, avoids showing unavailable delivery options, does not
impact other flows and aligns with the existing behavior during
checkout.
[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194
opw-5921268
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255066
Forward-Port-Of: odoo/odoo#250837This update corrects a visual issue where menu items on the website didn't align properly when using mobile view or hamburger menus. The fix adjusts how the menu items are styled, ensuring they align to the right or center based on the user's selection. This improves the overall user experience on mobile devices.
Original PR description
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop",…
Steps to reproduce: =================== 1- Enter the website editor 2- Enable mobile view 3- Edit the alignment of the mobile menu to be center or right aligned The group labels (e.g. "Shop", "Forum") stay left-aligned regardless of the chosen alignment. This can also be seen on desktop by switching to the sidebar header template. Cause: ====== The class .accordion-button uses `display:flex` and `text-align:left` and that class is used for the menu groups labels. this prevents the alignment from working. Solution: ========= When right-aligned (`text-end`), reverse the flex direction so the arrow moves to the left and the text stays on the right. When centered (`text-center`), let the text span fill the remaining space and center its content via `text-align: center`, keeping the arrow on its position. The default left-aligned case is unchanged. opw-5494765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244565
This update resolves an issue where cross-origin requests with the Range header were failing due to preflight checks. The change adds the necessary header to allow these requests to succeed, improving the reliability of external integrations. While future customization is considered, this fix addresses a specific, previously undetected problem.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This update fixes a technical error that prevented the generation of 281.10 reports for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information using pay slip line IDs. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users. This impacts the Ke edition of Odoo Enterprise.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing errors and improving the user experience for Italian businesses using the POS module. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update fixes a formatting issue in Odoo's XML files related to Danish VAT returns (OIOUBL21). The 'DK' prefix was missing, which is now added to the PartyIdentification text to ensure compliance with Danish tax regulations. This ensures accurate data transmission and avoids potential processing errors.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
This update addresses a previous issue where exporting XML from bills resulted in incorrect customer and supplier information. The button has been removed for non-self-bill invoices to prevent customer confusion. This ensures data integrity during import processes.
Original PR description
Problem --------- Currently, in the bills list view, when you select bills > Print > Export XML; not-imported bills gets their customer and supplier party inverted. This is because the XML export of those trigger the XML computation which is not designed for bills but only for invoices or self-bills. For imported bills (coming from Peppols for example), we re-use the imported XML. Since XML export of created bills is not supported anymore. The button leaves customers confused as to why their partner are inverted in the XML. Solution --------- Don't show the "Export XML" if one or more move are selected for the import and don't compute the XML for bills that are not self-bills. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug in Odoo's testing framework was causing freezes due to an infinite loop. This has been resolved by switching from an array to a set data structure, preventing the framework from repeatedly accessing the same data and avoiding the loop. This ensures the stability of the Odoo system.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely. Solution: Switched from using an `array` to `set` to prevent duplicate traversal. Task-6023290 Forward-Port-Of: odoo/odoo#255067 Forward-Port-Of: odoo/odoo#254857
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111439 Forward-Port-Of: odoo/enterprise#111290
This update ensures that all required address fields (street, city, zip, state, and country) are included when generating seller addresses on e-invoices for Viettel. This change is necessary to meet Viettel's EDI requirements and avoid potential invoice rejection issues, ensuring compliance and accurate reporting.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The issue stemmed from an inconsistent field being used instead of the correct variable, which could lead to an infinite loop. This fix ensures accurate leave accruals and prevents potential errors.
Original PR description
## Issue Oblivion regarding community-239836 The field `leaves_taken` (which shouldn't be accessed from the `_process_accrual_plans` method because it is inconsistent/can lead to infinite loop, see the related PR explanation) is used instead of the variable `leaves_taken`. robodoo up to saas-18.4 included Forward-Port-Of: odoo/odoo#253076
This update improves how charges are handled on invoices generated for UBL/BIS3 transactions. Instead of creating a new invoice line for charges, the charge amount is now directly added to the original invoice line's price unit. This ensures accurate and consistent reporting of charges on invoices.
Original PR description
Before this commit: A charge in an InvoiceLine was creating a new invoice line with the amount of the charge. After this commit: The charge is added in the price unit of the original line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254620 Forward-Port-Of: odoo/odoo#254111
This update resolves a technical issue causing emails to be rejected by strict email servers. By preventing the folding of subject headers, Odoo ensures emails are properly formatted and delivered, improving email communication reliability. This change aligns with best practices for email delivery.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. closes odoo/odoo#250388 See-also: #243119 Backport: #247057 Forward-Port-Of: odoo/odoo#254670