Daily updates from Odoo
Thursday, May 28, 2026
20 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where partner names with '&' characters were incorrectly formatted during SEPA export, leading to bank rejections. The fix ensures '&' is preserved in human-readable fields like partner names and addresses, aligning with banking standards and preventing export failures.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118511
Forward-Port-Of: odoo/enterprise#115409This update resolves an issue where Philippine withholding tax (WHT) repartition entries were incorrectly contributing to the periodic VAT closing process. By disabling this contribution, we ensure accurate and compliant VAT reporting for our Philippine users. This fix improves the reliability of financial data.
Original PR description
Set `use_in_tax_closing` to False on withholding tax (WHT) repartition lines, as they should not contribute to the periodic VAT closing entry. task-6146238 Forward-Port-Of: odoo/odoo#266623
This update resolves an issue where error handling for JSON responses within Odoo was failing due to inconsistencies in how the requests library parses JSON based on the simplejson library's presence. By patching the library, this ensures consistent error handling and prevents unexpected failures when processing external data.
Original PR description
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349 Forward-Port-Of: odoo/odoo#265031 Forward-Port-Of: odoo/odoo#264303
This update fixes a minor issue within the HTML editor where color selections weren't consistently updating in the toolbar. The team created a utility to wait for the browser's selection changes, ensuring the toolbar reflects the correct color before tests are run. This improves the reliability of the HTML editor's color selection functionality.
Original PR description
Before this commit: the test `cell's selected color should be shown in toolbar (3)` could fail when the bd color indicator isn't updated before the checking After this commit: we create an util to wait for the selectionchange event is fired by the browser to make sure the toolbar is updated before verifying. runbot-937780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266445
This update fixes a problem where vendor bills generated by external systems were missing item references in the PDF output. The change ensures that all product lines now correctly display the internal item reference, improving the accuracy and clarity of invoices. This ensures consistent and complete product information for our customers.
Original PR description
Some XML vendor bills generated by external ERPs were missing the Description tag, which typically contains both the [ITEM_REF] and ITEM_NAME. As a result, product lines in the generated PDF could appear without the internal item reference. This commit ensures that the item reference is always included in the displayed product line. task-6080328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259086
This update resolves a previous issue where transaction details weren't consistently saved for Viva Wallet payments, regardless of whether they were processed via webhook or polling. The fix ensures that all relevant payment information, including card details, is now accurately recorded, improving the reliability of our point-of-sale reporting.
Original PR description
After odoo/odoo#236454, a bug was introduced where the transaction details would only be saved if the payment was resolved via webhook, not via polling. This commit fixes the issue by using the same field names in the webhook payload as is received from the polling endpoint. In addition, the card number and card brand fields are now saved too. opw-6244960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266629
This update resolves a potential crash in Odoo's test cases related to how mail messages are handled. Specifically, the system now safely checks for `None` values before accessing a key attribute, preventing an error when a mail message isn't present. This enhances the reliability of our automated testing.
Original PR description
This changes https://github.com/odoo/odoo/pull/230766/changes cause the issue. I fix `AttributeError` when `mail_message` is None in `assertNoMail` method. The method was accessing `mail_message.message_id `without checking if `mail_message` is `None` first, causing a potential crash in test cases. Added a conditional check to safely handle None values before accessing the message_id attribute. @qrtl Forward-Port-Of: odoo/odoo#255720
This update fixes an issue where the expected hours displayed in the Attendances Gantt view didn't accurately reflect flexible work schedules, particularly when users' browsers were set to non-UTC timezones. The change ensures accurate hour calculations based on the user's local timezone, improving the reliability of attendance tracking.
Original PR description
Steps to reproduce: 1. Ensure your browser is in a non-UTC timezone (e.g. Europe/Zurich) 2. Set an employee to have a flexible working schedule 3. Enter the Attendances app 4. When hovering over the employee in the gantt view, the expected hours do not match their working schedule When we calculate the expected hours for the Gantt view in attendances, we calculate this based on an incorrect number of attendance intervals given from _attendance_intervals_batch(). To ensure that we recieve accurate intervals, we need to ensure that we calculate intervals based on the correct date range with respect to the browsers timezone, instead of the UTC date range. [opw-6175441](https://www.odoo.com/odoo/my-tasks/6175441?debug=assets) Forward-Port-Of: odoo/enterprise#116807
This update resolves an issue where attachments added to emails sent via the 'Send by Email' action were disappearing after refreshing the chatter window. The fix restricts attachment saving to the full composer view, ensuring consistent functionality across different email composer types. This improves the reliability of sending emails with attachments.
Original PR description
**Steps to reproduce:** - Install Sales app - Create a Sales Order - Click on the 'Send by Email' action - Add an attachment and send it - Open the chatter to create a log note - Attachment is…
**Steps to reproduce:** - Install Sales app - Create a Sales Order - Click on the 'Send by Email' action - Add an attachment and send it - Open the chatter to create a log note - Attachment is attached to the new message - It disappears on refresh **Issue:** Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`. Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers. But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`. **Fix:** Restrict the attachment save to the full composer using context. [1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027 [2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3 opw-5164504 Forward-Port-Of: odoo/odoo#266091 Forward-Port-Of: odoo/odoo#265736
This update resolves an issue where setting Intrastat fields on product templates without associated products would trigger an error. The fix ensures that the system correctly handles scenarios where product variants are not defined, preventing unexpected errors and improving data consistency.
Original PR description
Problem: The Intrastat fields on product.template are computed without being stored. They are stored in product.product and the same values are used when computing the values on product.template. When trying to set the Intrastat fields on a product template without any product, an RPC error is raised without specifying the reason. Steps to reproduce: 1. Create a new product (product.template) 2. Add an attribute to the product with Variant Creation set to Dynamic, this will set no product variants (product.product) for the product template. 3. Try to set the Intrastat Commodity Code on the product template 4. Save the product template 5. Notice the RPC error raised without any explanation opw-6179705 Forward-Port-Of: odoo/enterprise#117856
This update fixes a bug where broken link trackers were appearing in the list and prevents users from creating trackers with invalid codes. The system now ensures tracker codes are valid and disables editing the target link after tracker creation, streamlining the process and improving data accuracy.
Original PR description
1. Remove the possibility to create link tracker with an empty code. Empty code tracker do not work, but still appear in the tracker list. Only accept alphanumerical chars in the tracker code. 2. Set the target link input as disabled after generating the tracker, since editing the target link at this point would have no impact. task-4531974
This update fixes an issue where new link previews in the technical view displayed a technical ID instead of a user-friendly 'New' label. The change ensures a cleaner and more intuitive experience for users creating link previews, showing 'New' until saved and the actual URL upon saving.
Original PR description
**Problem:** Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard…
**Problem:**
Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard "New" label.
**Steps to reproduce:**
1. Settings / Technical / Discuss / Link Previews
2. New
3. Observe the breadcrumb
**Current behavior:**
The breadcrumb displays `mail.link.preview,<id>`.
**Expected behavior:**
The breadcrumb should display "New" until the record is saved, and the source URL once saved.
**Cause of the issue:**
The model defines no `name` field and does not set `_rec_name`, so the default `_compute_display_name` falls into its fallback branch and returns `f"{record._name},{record.id}"` — exposing the technical reference in the breadcrumb both for unsaved records (`NewId_...`) and saved ones.
**Fix:**
Setting `_rec_name = 'source_url'` lets the standard display name machinery compute a meaningful label from the existing required field. Unsaved records then surface the standard "New" placeholder via the web client and saved records surface their URL, without introducing a redundant `name` field or overriding the compute.
opw-6095012
Forward-Port-Of: odoo/odoo#263577This update resolves a technical issue preventing Viva payments in the POS kiosk. The Viva payment system requires a unique identifier for the cash register, which was previously missing. This fix ensures the correct 'cashRegisterId' is sent, allowing Viva payments to process successfully and avoiding errors.
Original PR description
When validating a payment in POS Kiosk with Viva payment method we get a Viva.com error Viva’s card-terminal API validates the JSON body with Pydantic and requires a non-empty ``cashRegisterId``. Steps to reproduce: ------------------- * Open POS in kiosk * Make an order and pay with Viva > Observation: Viva returns a validation error: ``cashRegisterId`` is missing or required in the request body (Pydantic ``missing`` on ``body.cashRegisterId``). Why the fix: ------------ Compute ``cashRegisterId`` in the POS client as cashier name, then ``pos.config.name`` so the value is always a non-empty string sent to ``viva_wallet_send_payment_request``. opw-6091223 Forward-Port-Of: odoo/odoo#265817 Forward-Port-Of: odoo/odoo#258605
This update upgrades the Windows installer to use PostgreSQL 16, addressing the outdated and unsupported PostgreSQL 12 version. Additionally, the installer now uses a dedicated Odoo user for database connections, enhancing security and stability. This change ensures compatibility with current PostgreSQL standards and best practices.
Original PR description
The Windows installer installs PostgreSQL 12. That version was chosen for its small size, but now in 2026 the size doesn't matter as much anymore. Also, version 12 is no longer supported, so it's time to bump to version 16. While at it, this commit adds an Odoo user for the PostgreSQL connection instead of using the superuser. Forward-Port-Of: odoo/odoo#266059 Forward-Port-Of: odoo/odoo#265134
This update resolves a compatibility issue with a key library used to handle XML data within Odoo. The change ensures Odoo continues to function correctly with the latest version of the lxml library, which is a foundational component. This update is a routine maintenance task.
Original PR description
Note: support for version 6+ of lxml has been merged in odoo/odoo@4b1797fccdf1447a8adb817148cc39bc322428a6 runbot-938365 Forward-Port-Of: odoo/odoo#266627
This update fixes a potential issue where users could inadvertently select inactive Intrastat codes when setting them on products. The system now displays a warning message, preventing users from selecting invalid codes and ensuring data accuracy for reporting. This improves data integrity and reduces the risk of errors.
Original PR description
Problem: When choosing an intrastat code on a product, all the codes are shown, even the ones that are expired or not yet active. Users can select an intrastat code that is not active. Steps to reproduce: 1. Check the intrastat code list and find a code with a start date in the future or an expiry date in the past 2. Note the code description 3. Open a product form view and try to set/change the intrastat code 4. Search for the code description noted in step 2 5. Note that the code is proposed while it should not be proposed Solution: When an intrastat code is selected, if the code is not active, a warning message is shown to the user. opw-6217915 Forward-Port-Of: odoo/enterprise#118417 Forward-Port-Of: odoo/enterprise#117884
This update fixes an issue where the import process wasn't correctly reading invoice due dates from FatturaPA invoices. Now, the system accurately captures the due date for issued invoices, ensuring proper payment tracking. This resolves a previous error that defaulted due dates to today's date.
Original PR description
The import procedure stopped reading DataScadenzaPagamento (invoice date due) on `out_invoice`s and `in_refund`. As a side effect, invoice_date_due fell back to today() on those documents. This commit restores reading the invoice date due, and keeps the condiitonal logic only for the bank account and payment_reference logic incoming-only as it was before. Forward-Port-Of: odoo/odoo#264762 Forward-Port-Of: odoo/odoo#264573
This update ensures that the project associated with a sales order is automatically included in the generated Manufacturing Order, even with multi-step delivery routes (Pick + Deliver). Previously, this wasn't happening, causing issues with tracking projects in complex order flows. This change improves order management and reporting accuracy.
Original PR description
### Issue before this commit: When confirming a Sale Order with multi-step delivery routes (Pick + Deliver), the generated Manufacturing Order did not inherit the project_id from the Sale Order, even…
### Issue before this commit: When confirming a Sale Order with multi-step delivery routes (Pick + Deliver), the generated Manufacturing Order did not inherit the project_id from the Sale Order, even though the project was correctly set on the SO. ### Steps to reproduce the issue: 1. Download Inventory, Sales, PLM, Project 2. Enable multi-step routes in settings and unarchive MTO from routes 3. Go to Products and modify 1. Furniture Assembly inserting Project in "Create on Order" attribute and a test project template 2. Drawer selecting MTO and Manifacture in Inventory tab 4. Create a new quotation inserting 2 products: Furniture Assembly and Drawer and confirm it 5. Go to "Manufacturing" smart button 6. See in Miscellaneous tab the Project is setted as default 7. Go to warehouses, select the WH of your company and select Pick then Deliver (2 steps) as Outgoing Shipments 8. Go to Routes, select Deliver in two steps (pick + ship) and change "Destination location" of "Pull From" from Parteners/Customers into WH/output 9. Go to Rules: 1. "Pull From" (the one with Partener/Customers as destination location and MTO as route): change "Destination location" of from Parteners/Customers into WH/output 2. "Push To" (the one with Partener/Customers as destination location and with the deliver in 2 steps as route): change action from "Push To" to "Pull from" 10. Create a new quotation inserting 2 products: Furniture Assembly and Drawer and confirm it 5. Go to "Manufacturing" smart button 6. See in Miscellaneous tab the Project is not setted ### Cause of the issue: https://github.com/odoo/odoo/blob/d1955028bb95eff8d33c1c2b1c211d8520bb33a2/addons/sale_project_stock/models/stock_move.py#L71-L76 This function retrieves the project only based on the sale_line_id, which is correctly populated in a one-step delivery because the procurement is directly linked to the Sales Order (SO). However, the sale_line_id is not propagated to procurements that are not directly linked to the SO. In this scenario, with a two-step delivery, there are two stock moves: from Stock to WH/Output, and from WH/Output to the Customer. Only the second move (WH/Output > Customer) is linked to the SO, while this information is not propagated to the first move. As a result, the project_id information is lost. ### Reason to introduce the fix: Be sure that the project is automatically setted in the MO when a SO is confirmed whatever the intial delivery configuration is. opw-5913988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266808 Forward-Port-Of: odoo/odoo#261565
This update fixes a bug in the calculation of discounts and subtotals on invoices with both product and global discounts. The change ensures accurate financial reporting by correcting a discrepancy in the test case results. This improves the reliability of invoice totals.
Original PR description
Purpose: A bug was found in the calculation of the `raw_discount_amount` and `raw_gross_total_excluded` when `_add_and_round_raw_gross_total_excluded_and_discount` is called on an invoice that contains both product line discounts and global discounts. Therefore, the discount and subtotal amounts for the test case testing both line and global discounts need to be corrected to ensure accurate test coverage. opw-5412446 Forward-Port-Of: odoo/enterprise#115855
This update fixes an issue where the calculation of the gross total on invoices with both line and global discounts was incorrect. The change ensures that discounts are applied in the correct order, resulting in accurate gross total calculations for invoices, particularly when global discounts are involved. This improves the reliability of invoice totals.
Original PR description
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact…
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines. Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10) = 98.889 This does not equal the expected outcome of $100. Expected Behavior: Based on the previous example, the formula for the calculation should be: (raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9 = 100 The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts. Steps to reproduce the issue: - Bug was encountered when implementing a global discount solution for l10n_co_dian. - Create an invoice with a product line and in-line discount and another line for global discount - Setup the base lines for the invoice and attempt the following: - _dispatch_global_discount_lines - _squash_global_discount_lines - _add_and_round_raw_gross_total_excluded_and_discount opw-5412446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262137