Odoo Changelog — 2026-04-22

Wednesday, April 22, 2026

243 changes

Branch: saas-19.3

24 changes

Bug Fixes(24)

Resolved issues and error corrections

[FIX] lxml: change version of patch obsolescence

PR #260652

Coresaas-19.3odoo

This change updates an internal compatibility check for the lxml library so Odoo correctly recognizes when an older workaround is no longer needed. It helps keep the system aligned with the latest lxml release behavior, reducing the risk of unnecessary patches being applied.

Original PR description

Whitelisting of ARIA attributes is now part of the milestone for LXML 6.1. This commit updates monkey patch's obsolescence detection accordingly.

Forward-Port-Of: odoo/odoo#258910

#lxml#accessibility#compatibility#maintenance

[FIX] account: attach imported XMLs

PR #260640

Coresaas-19.3accountaccount_edi_ubl_ciiMEDIUM

Imported XML files now stay properly attached to the related bill instead of being detached during import. This prevents access errors when users later open documents created from email or manual imports, including cases used by local e-invoicing flows.

Original PR description

When importing files (manually or from email alias),
we unattach the xml files, it can lead to access error in some flows
like with l10n_mx_edi

Steps to reproduce the flow that triggered the bug:

- Install l10n_mx_edi and select MX company
- Create an email alias for purchase journal
- Receive email with xml file
- Create a user with 'group_user' role, 'Administrator' accounting
  access rights
- Login with this user and open the created bill
-> Access Error

This is because we unattach xml attachmentss when importing them, by setting
`res_id` to 0 and `res_model` to False.
The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via
`_get_mail_thread_data_attachments` which lead to an access error during the
`fetch` method

opw-5953578

Forward-Port-Of: odoo/odoo#260127
Forward-Port-Of: odoo/odoo#259095

#invoice import#attachments#access error#email alias#e-invoicing

[FIX] Spreadsheet: neutralize odoo links on freeze

PR #260502

Coresaas-19.3spreadsheetMEDIUM

This change preserves the visual link styling in shared frozen spreadsheets while preventing those links from being clickable. It helps dashboards keep their intended layout and appearance without exposing internal navigation behavior.

Original PR description

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

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#260250
Forward-Port-Of: odoo/odoo#256357

#spreadsheet#freeze and share#links#dashboard styling

[FIX] web: image not visible in printed PDF when resized to percentage

PR #260657

Coresaas-19.3webMEDIUM

Images added to the document layout now remain visible in printed PDFs even when their width is set as a percentage. This fixes an issue where company details could lose the image in the final printout, improving the reliability of document branding.

Original PR description

Problem:
When adding an image in the `company_details` field via **Settings > Configure your document layout** and resizing it to a percentage width (e.g. 50%), the image is not visible when printed.

Cause:
Since fa55c2d1, `wkhtmltopdf` fails to correctly calculate percentage-based image widths because none of the ancestor elements have an explicit width defined.

Solution:
Force the wrapping table to `width: 100%`, giving `wkhtmltopdf` a concrete width to resolve percentage values against.

Steps to reproduce:
- Go to **Settings > Configure your document layout**
- In the address field, add an image via `/media`
- Resize the image to 50%
- Print the document
- Image is missing in the PDF output

opw-6102568

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#259077

#pdf#printing#document layout#image

[FIX] sale_mrp: fix no COGS entry when kit component deleted in delivery

PR #260644

Coresaas-19.3sale_mrpstockaccountMEDIUM

This fix restores the cost of goods sold entry when a kit is delivered with some components removed. It also improves the accounting amount by charging only for the components that were actually delivered, which makes the invoice records more accurate.

Original PR description

Steps to reproduce:
- Create a kit with 3 or more components
- Create a sales order with the kit and confirm it
- Remove at least one of the kit's components from the delivery and validate it
- Create the invoice from the sales order and confirm the invoice
- Check the journal entries included in the invoice form

Current behavior:
- There is no COGS entry

Expected behavior:
- There should be a COGS entry

Context:
In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount.

opw-6082565

Forward-Port-Of: odoo/odoo#259875
Forward-Port-Of: odoo/odoo#258982

#kits#cogs#invoicing#delivery#accounting

[FIX] html_editor: fix non-deterministic icon test

PR #260656

Coresaas-19.3html_editor

This change fixes an unreliable automated test in the HTML editor, making test results more consistent. It helps ensure future builds are less likely to fail randomly, improving confidence in the editor’s quality without changing the user experience.

Original PR description

My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones.

runbot-242333

Forward-Port-Of: odoo/odoo#259978
Forward-Port-Of: odoo/odoo#259544

#testing#stability#html editor

[FIX] stock: prevent traceback when confirming scrap after discard

PR #260663

Coresaas-19.3stockMEDIUM

This change prevents a crash that could happen when a user tried to confirm a scrap operation after first dismissing the insufficient-quantity warning. It keeps the process stable and avoids interrupting inventory work with an error message.

Original PR description

**Version:** --------- - saas-19.2+ **Steps to reproduce:** ------------------------ * Install the *Inventory (stock)* module. * Create a *storable product* with tracking enabled. * Update the…

**Version:**
---------
- saas-19.2+

**Steps to reproduce:**
------------------------
* Install the *Inventory (stock)* module.
* Create a *storable product* with tracking enabled.
* Update the on-hand quantity to *5 units*.
* Navigate to *Inventory > Operations > Scrap* and create a new scrap
  record.
* Select the created product and set a quantity *greater than the
  available on-hand quantity (e.g. 6)*.
* Click on *Confirm*.
* An *insufficient quantity* wizard opens.
  * Click on *Discard*.
  * Then click again on *Confirm* in the wizard.

**Issue:**
---------
* A traceback occurs with the following error:
  `ValueError: Expected singleton: stock.move()`

**Cause:**
----------
* When clicking *Confirm*, button the insufficient quantity wizard is opened
  with a `scrap_move_id`.
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2747
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2742
* Clicking *Discard* button triggers `action_cancel`, which unlinks the
  associated `scrap_move_id`.
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L48-L49
* However, the wizard remains open, and clicking *Confirm* again
  triggers `action_done`, which calls:
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L46
* At this point, `scrap_move_id` no longer exists, leading to the
  singleton error.

- Before saas-19.2
This behavior was previously handled in:
https://github.com/odoo/odoo/commit/c361c3778ef4755b4760039a4fd8f9ed88294b64

Later in this commit https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba
the condition was removed during refactoring, causing the scrap move is to be unlinked in all flows.

**Fix:**
------
* Add a context key to ensure that the scrap move is only unlinked
  during the `action_scrap` flow, preventing access to a deleted
  `scrap_move_id`.

---

opw-6128188


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#260121

#inventory#scrap#warning#crash#user experience

[FIX] mail: add missing picture-in-picture action in call menu

PR #260748

Coresaas-19.3mail

The call menu now includes the Picture-in-Picture option, making it faster to keep a call visible while moving to another conversation. The menu also fixes the appearance of Fullscreen and Picture-in-Picture so these options display normally instead of looking faded.

Original PR description

Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…

Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call.

Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster.

This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature.

Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown.

Before / After
<img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" />

Forward-Port-Of: odoo/odoo#260512
Forward-Port-Of: odoo/odoo#259866

#discuss#call menu#picture-in-picture#fullscreen#ui

[FIX] html_editor: fix non-deterministic power buttons test

PR #260653

Coresaas-19.3html_editor

This change makes an automated test for the editor’s power buttons more reliable on slower systems. It avoids false failures caused by timing differences, so test results are more stable without changing the product behavior.

Original PR description

Waiting for a full animation frame is too dangerous. In the general case, an animation frame happens every 16ms, in which case the power buttons haven't been updated yet since they have a debouncing timeout of 30ms. However, when the runbot is slow, more than 30ms may very well have elapsed between two animation frames. When that is the case, the power buttons are displayed and the test fails.

This commit changes the forced awaiting of an animation frame to a waiting pased on the time passed. In the general case, an animation frame will have happened in 20ms, so the test will still catch a regression. When the runbot is slow however, more time might have passed, but not necessarily an animation frame, so the power buttons should still be invisible, making this test more reliable.

runbot-242466

Forward-Port-Of: odoo/odoo#259854
Forward-Port-Of: odoo/odoo#259654

#testing#stability#reliability#editor

[FIX] mrp_subcontracting_purchase: add PO source link on mtso resupply pickings

PR #260654

Coresaas-19.3mrp_subcontracting_purchasestock

When a subcontractor resupply picking is created through a stock-triggered route, it now correctly displays the originating purchase order. This makes it easier for users to trace the supply flow and understand which order the picking belongs to.

Original PR description

### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route,…

### Steps to reproduce:

- In the settings enable: Subcontracting, Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Routes
- Edit the 'Resupply Subcontractor on Order' route, rules supply method to: Take from stock, if unavailable, trigger another rule (mtso)
- Create a subcontracted bom For a product P with a component COMP
- Create and confirm a PO for 1 unit of P with your subcontractor
- Use the Resupply smart button to access the resupply picking
#### > The resupply picking does not refer to the source PO

### Cause of the issue:

The link is currently computed based on `move_dest_ids` which are only set for mto moves. However, moves created from mtso rules are `make_to_stock`.

### Fix:

Since 19.0 2713876dbc70d3984e584a9037a2206dcda4e84a, we can rely on references to rebuild the link between the resupply picking and the source PO even in mtso. Note that this will also add the source PO link to each other picking of the reference.

opw-6079680

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#256689

#subcontracting#purchase order#resupply#traceability

[FIX] account_intrastat: fix missing intrastat on autocomplete

PR #114619

Enterprisesaas-19.3account_intrastatMEDIUM

When a vendor bill is created using Auto-complete from a previous bill, the Intrastat transaction information is now preserved on the new bill lines. This prevents missing customs/trade reporting data and helps ensure the bill is completed correctly from the start.

Original PR description

Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to…

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Forward-Port-Of: odoo/enterprise#114520
Forward-Port-Of: odoo/enterprise#112857

#intrastat#vendor bill#auto-complete#reporting

[FIX] mail: correct text color on mail message focus

PR #260605

Coresaas-19.3mailMEDIUM

This change keeps the message text readable when a reply box is active in Discuss, Helpdesk, and product reviews. It prevents the text color from turning white on a white background when users click into the message field, improving usability in dark website themes.

Original PR description

# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…

# Setup
Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white.

# How to reproduce
- Install the Helpdesk app
- Go to Website > Help
- Submit a ticket (the ticket's information is not important)
- Click the ticket link shown when the ticket is submitted
- Start writing a message in the Communication History.

# The problem
As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable.

Note : the same problem is present for product reviews in the eCommerce application.

These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103

# Cause
The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131

In our case, it sets `color` to #FFF  (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101

But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149

The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6

Because `.o-discuss-text-body` is overriden by  `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied.

# Proposed solution
Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused

opw-6063961

#ui#theme#readability#helpdesk#ecommerce

[FIX] account_reports: fix date format year

PR #114620

Enterprisesaas-19.3account_reports

This fix ensures return documents show the correct year in their date range labels. It prevents cases where a January 2023 date was incorrectly displayed as January 2022, which could cause confusion when reviewing reports or records.

Original PR description

Steps to reproduce:
 - Create a return from Jan 2023 to April 2023 -> the dates displayed in the name will be Jan 2022 - Apr 2023

The display is incorrect because we used the wrong date format, and therefore switch from using YYYY to yyyy as the first one is the ISO standard year and the second the calendar year. They might differ on the result here because 01 Jan 2023 falls on a Sunday, but ISO week starts on Monday, so it took the previous year (2022)

Forward-Port-Of: odoo/enterprise#114428

#dates#display#reporting

[FIX] iot: do not overwrite user chosen subtype

PR #114625

Enterprisesaas-19.3iotMEDIUM

This fix ensures that when an IoT-connected printer is refreshed, its subtype is not overwritten if someone has already changed it in the database. As a result, business users keep their chosen device settings instead of seeing them reset after an IoT box restart.

Original PR description

Steps to reproduce:

1. Connect a printer to the IoT box and pair with a DB
2. Manually change the subtype of the printer in the DB
3. Restart the IoT box so it resends its devices.

**Expected behaviour**: Subtype remains as the user-set value.

**Actual behaviour**: Subtype is reset to the original value.

To fix this issue, we simply remove any check for subtype in the device updating condition. Now, a device will only reset if its type changes.

Forward-Port-Of: odoo/enterprise#114416

#iot#printer#device settings#data preservation

[FIX] sale_renting_planning: check for resource leaves without related resource

PR #114633

Enterprisesaas-19.3sale_renting_planningMEDIUM

This fix ensures that calendar leave entries created without a specific resource are no longer ignored. Instead, they are applied to all resources as intended, helping avoid scheduling mistakes in renting plans.

Original PR description

Before this commit, any `Resource Calendar Leave` created with no `Resource` related to it was ignored, while it should have been applied to all `Resources`. This commit makes sure that any `Resource Calendar Leave` with no related `Resource` is applied to all `Resources` as intended.

task-5798796

Forward-Port-Of: odoo/enterprise#114274
Forward-Port-Of: odoo/enterprise#112575

#planning#calendar#availability#renting

[FIX] l10n_lu_hr_payroll: Fix wrong compute method on field

PR #114655

Enterprisesaas-19.3l10n_lu_hr_payrollMEDIUM

This update corrects how one payroll field is calculated in the Luxembourg payroll module. It helps ensure employee payslips are computed with the right logic, reducing the risk of incorrect payroll results.

Original PR description

Forward-Port-Of: odoo/enterprise#107635

#payroll#payslip#calculation#luxembourg

[FIX] documents: fix share panel behavior with select all

PR #114639

Enterprisesaas-19.3documentsMEDIUM

When using Documents with a large selection, the Share action now correctly applies permission changes to every selected file, not just those on the current page. This prevents inconsistencies when working with more than one page of documents.

Original PR description

**Steps to reproduce:**
- Install Documents app
- Upload more than 80+ files (max page size is 80)
- Use the checkbox to select all files on the page
- Click the 'Select All' button in the control panel to select allfiles
- Use Share action button
- Pop-up only takes the current page into account
- Rights modifications will not be applied on remaining records

**Issue:**
`onShare()` only takes current records into account even if the full selection was applied.

**Fix:**
Fetch all document ids (if needed) before opening the dialog.

opw-5957777

Forward-Port-Of: odoo/enterprise#110299

#documents#sharing#selection#permissions

[FIX] helpdesk_stock: allow copying tickets without stock rights

PR #114630

Enterprisesaas-19.3helpdesk_stockhelpdesk_stock_accountMEDIUM

This change fixes an error that could block users from duplicating Helpdesk tickets when they do not have stock permissions. It makes ticket copying work smoothly for more users without requiring extra access rights, reducing interruptions in daily support work.

Original PR description

Steps to reproduce:
- Install helpdesk_sale_timesheet.
- Create a Helpdesk Ticket and set its sale_line_id.
- Log in as a user without stock.group_stock_user access.
- Try to duplicate the ticket.

Issue:
Duplicating a ticket raises an AccessError because the user
lacks stock rights required when copying the product_id.

Fix:
Set `product_id` to False during duplication for non-stock users.
Reference: https://github.com/odoo/enterprise/pull/9100

task-5356318

Forward-Port-Of: odoo/enterprise#114266
Forward-Port-Of: odoo/enterprise#101338

#helpdesk#access rights#duplicate#refund#stock permissions

[FIX] account,purchase: make purchase move view work with old version

PR #260758

Coresaas-19.3accountpurchaseMEDIUM

This update prevents an error that could occur when the Purchase app is installed after Accounting on an existing system. It makes the Purchase screen adapt safely to older versions of the Accounting view, improving upgrade and installation reliability.

Original PR description

c5ac4867fb708c56aa74e38508347660f1875dd3 added back the computed fields `invoice_vendor_bill_id` and `purchase_vendor_bill_id` on `account.move` in stable.

The issue is that the view on purchase expects the view on account to have `invoice_vendor_bill_id` in it.
But if a user already had `account` installed before the commit, then install `purchase` after, the purchase view will raise an exception as it expects `invoice_vendor_bill_id` in the view of account.

The fix here is to not reference `invoice_vendor_bill_id` in the purchase view and compute its visibility with a non-stored computed field.

Forward-Port-Of: odoo/odoo#260151

#upgrade#installation#compatibility#views

[FIX] sale_loyalty: only apply currency rounding on money-based programs

PR #260650

Coresaas-19.3sale_loyaltyMEDIUM

This fix ensures loyalty points are only rounded like money when the program is actually money-based. As a result, point-based rewards will no longer be reduced to zero in currencies with coarse rounding rules, so customers can claim their rewards as expected.

Original PR description

`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable.

Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules.

opw-6111622

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#259660

#loyalty#rewards#currency rounding#points

[FIX] website,mass_mailing: fix typo

PR #260796

Coresaas-19.3websitemass_mailing

This update fixes a small wording mistake in website and mass mailing text snippets, changing “am” to “pm” where needed. It helps ensure opening hours and related customer-facing content are accurate and less confusing.

Original PR description

am to pm

Forward-Port-Of: odoo/odoo#260577

#typo#text#opening-hours#customer-facing

[16.0][FIX] l10n_ch: filter characters for QR codes

PR #260761

Coresaas-19.3l10n_chMEDIUM

This change filters out characters that are not allowed in Swiss QR bills before the QR code is generated. It helps prevent bank rejections caused by unsupported Unicode characters, improving payment reliability.

Original PR description

**Description of the issue/feature this PR addresses:**

QR code is rejected by the bank, when it contains an invalid character `U+202F`.

**Current behavior before PR:**

Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part.

**Desired behavior after PR is merged:**

Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out.

> spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#259279
Forward-Port-Of: odoo/odoo#254980

#switzerland#qr-bill#payments#banking

[FIX] spreadsheet_dashboard_voip: Fix typo & style in dashboard

PR #114686

Enterprisesaas-19.3spreadsheet_dashboard_voip

This update fixes a typo and improves the visual styling in the VoIP dashboard used with spreadsheets. It does not change how the feature works, but it helps make the interface clearer and more polished for users.

Original PR description

task-6132220

Forward-Port-Of: odoo/enterprise#114324

#ui#dashboard#copy#style

[FIX] project: prevent traceback in mobile view

PR #260792

Coresaas-19.3projectMEDIUM

This update prevents a crash when users open the “Blocked by” tab and add a dependency from a mobile device in Project. It ensures the interface loads correctly, improving reliability for teams managing tasks on the go.

Original PR description

Steps to reproduce:
- Install Project
- Create a project and a task and enable task dependencies
- In mobile view, go to the "Blocked by" tab and click "Add"

Issue:
A traceback occurs in the mobile view.

Cause:
In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element.

Fix:
Update the XPath to correctly replace the element containing parent_id.

task-6009997

Forward-Port-Of: odoo/odoo#252804

#mobile#task dependencies#traceback#ui stability

Branch: saas-19.2

7 changes

Bug Fixes(7)

Resolved issues and error corrections

[FIX] website_sale: Filter categories by current website on product page

PR #260391

Coresaas-19.2website_saleMEDIUM

When a product belongs to categories used on multiple websites, the site now chooses a category that is accessible on the current website. This prevents customers from clicking a breadcrumb link and landing on a 404 page when browsing a different website.

Original PR description

An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories. Steps to Reproduce: ==================== 1. Create two…

An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories.

Steps to Reproduce:
====================
1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2.
2. Create a product and assign both categories to it.
3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly
4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error**

Cause:
======
In `_prepare_product_values`, when no category is passed in the URL, the fallback was:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802

This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2.
The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404.

Solution:
=========
Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one.

opw-6070191

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#258336

#website#ecommerce#breadcrumb#category#404

[FIX] website_sale: xml template issue with empty foreach on normalization

PR #256605

Coresaas-19.2salewebsite_salebaseMEDIUM

This change fixes an issue that could prevent certain sales-related email templates from being saved correctly in the editor. It makes the template content stay in a valid structure during editing, so users no longer run into unexpected save errors.

Original PR description

**Steps to reproduce:** - Install sale / website_sale - In debug mode, go to Settings app - Go to Technical > Email > Email Templates - Try to edit and save "Sales: Order Confirmation" or "Ecommerce:…

**Steps to reproduce:**
- Install sale / website_sale
- In debug mode, go to Settings app
- Go to Technical > Email > Email Templates
- Try to edit and save "Sales: Order Confirmation" or "Ecommerce: Cart Recovery"
- QWebError is raised: 'IndentationError: unexpected indent'

**Issue:**
Before a `mail.template` is rendered in the html editor it must be valid html (even if they contains qweb elements) to avoid the browser silently moving elements around to match its specifications (and breaking template logic). This is also what happens with  `DOMParser.parseFromString` function.

e.g. the browser moves html elements out of the parent `<table>` if they are not the children of a `<tr>` `<td>`.
```xml
<table>
    <t t-foreach=...>
        <tr>
            <td>1</td>
        </tr>
    </t>
</table>
```
Becomes:
```xml
<t t-foreach=...>
</t>
<table>
    <tbody>
        <tr>
            <td>1</td>
        </tr>
    </tbody>
</table>
```

**Fix:**
The template is still working if not edited, but we need to ensure the template `body_html` is valid html to avoid the hierarchy modification.

related: https://github.com/odoo/odoo/commit/dbd8b879fd95f3e913e1c777cb8619c4e0673b03
similar issue: https://github.com/odoo/odoo/pull/259548

opw-6055026

#email templates#website sale#sales#editor#qweb

[FIX] sale_mrp: fix no COGS entry when kit component deleted in delivery

PR #260534

Coresaas-19.2sale_mrpMEDIUM

This update fixes an accounting issue where invoices for kits could miss the cost of goods sold entry if one or more kit components were removed from the delivery. It now records the cost based on the components that were actually delivered, which keeps invoice accounting accurate and more reflective of the real shipment.

Original PR description

Steps to reproduce:
- Create a kit with 3 or more components
- Create a sales order with the kit and confirm it
- Remove at least one of the kit's components from the delivery and validate it
- Create the invoice from the sales order and confirm the invoice
- Check the journal entries included in the invoice form

Current behavior:
- There is no COGS entry

Expected behavior:
- There should be a COGS entry

Context:
In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount.

opw-6082565

Forward-Port-Of: odoo/odoo#259875
Forward-Port-Of: odoo/odoo#258982

#cogs#invoice#kit#delivery#accounting

[FIX] documents: fix share panel behavior with select all

PR #113883

Enterprisesaas-19.2documentsMEDIUM

When users select all documents across multiple pages and open the Share action, the system now correctly applies permission changes to every selected document, not just the ones visible on the current page. This prevents incomplete sharing updates in large document lists.

Original PR description

**Steps to reproduce:**
- Install Documents app
- Upload more than 80+ files (max page size is 80)
- Use the checkbox to select all files on the page
- Click the 'Select All' button in the control panel to select allfiles
- Use Share action button
- Pop-up only takes the current page into account
- Rights modifications will not be applied on remaining records

**Issue:**
`onShare()` only takes current records into account even if the full selection was applied.

**Fix:**
Fetch all document ids (if needed) before opening the dialog.

opw-5957777

Forward-Port-Of: odoo/enterprise#110299

#documents#share#selection#multi-page#permissions

[FIX] account_reports: don't crash when comparing with 1 period on a report containing a string value

PR #114296

Enterprisesaas-19.2account_reportsMEDIUM

The annual tax report now handles comparison values more safely, even when the report contains text entries. This prevents a crash when users compare the report with one previous period, so the comparison view opens normally.

Original PR description

To reproduce:
- Create a company in LU
- Open the annual tax report for LU
- Click on the comparison filter, compare with 1 period in the past

==> Traceback.

This happens because that report contains a string value (an editable one, but it's not important here). Since there are only 2 comparison periods, we try creating the "%" column, comparing their amounts. The condition checking whether or not to display "N/A" was wrong, as it considered the values could only be int/float or None. Here, they are strings, so we don't enter that condition and crash when trying to evaluate float_is_zero on a string.

Forward-Port-Of: odoo/enterprise#113330
Forward-Port-Of: odoo/enterprise#112619

#bugfix#reports#comparison#tax report

[FIX] website,mass_mailing: fix typo

PR #260730

Coresaas-19.2websitemass_mailing

This update fixes a small wording error in website and mass mailing snippets, changing “am” to “pm” where needed. It helps ensure displayed opening hours and related content are accurate and less confusing for visitors.

Original PR description

am to pm

Forward-Port-Of: odoo/odoo#260577

#copy fix#opening hours#text correction

[FIX] project: prevent traceback in mobile view

PR #260731

Coresaas-19.2projectMEDIUM

This change prevents an error that could appear when users add task dependencies from the mobile Project view. It ensures the correct part of the screen is updated, so the action works reliably on mobile devices.

Original PR description

Steps to reproduce:
- Install Project
- Create a project and a task and enable task dependencies
- In mobile view, go to the "Blocked by" tab and click "Add"

Issue:
A traceback occurs in the mobile view.

Cause:
In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element.

Fix:
Update the XPath to correctly replace the element containing parent_id.

task-6009997

Forward-Port-Of: odoo/odoo#252804

#mobile#project tasks#dependencies#bug fix

Branch: saas-19.1

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] documents: fix share panel behavior with select all

PR #113880

Enterprisesaas-19.1documentsMEDIUM

The Documents app now correctly applies sharing changes to every document selected, even when the selection spans more than one page. This prevents rights updates from being applied only to the visible page and ensures the action matches what the user selected.

Original PR description

**Steps to reproduce:**
- Install Documents app
- Upload more than 80+ files (max page size is 80)
- Use the checkbox to select all files on the page
- Click the 'Select All' button in the control panel to select allfiles
- Use Share action button
- Pop-up only takes the current page into account
- Rights modifications will not be applied on remaining records

**Issue:**
`onShare()` only takes current records into account even if the full selection was applied.

**Fix:**
Fetch all document ids (if needed) before opening the dialog.

opw-5957777

Forward-Port-Of: odoo/enterprise#110299

#documents#sharing#selection#user-experience

[FIX] hr_attendance: updating overtimes TZ issue

PR #260772

Coresaas-19.1hr_attendanceMEDIUM

This fix prevents a crash when overtime records are recalculated for employees whose attendance starts or ends at midnight in their time zone. It makes overtime updates more reliable when Absence Management is enabled and an overtime rule is in use.

Original PR description

**Context**
- "Absence Management" is enabled in the database settings
- Employee has an overtime ruleset selected in their employee settings
- That overtime ruleset has a rule with a non-zero `expected_hours`
- That employee has 1 or more attendance records that start or end at midnight in their timezone.

**Before this commit**
When updating overtime records, either via the "Regenerate overtimes" button on the overtime rule, or by simply creating a new attendance record, we'll end up passing around an intervals object that contains no intervals. Then, when we later assume this object will have at least one element, we crash.

**After this commit**
Guarantee that intervals objects are populated before assuming they are. Further, we remove the opportunity to create an empty intervals object that was exposing this bug.

opw-6035270

Forward-Port-Of: odoo/odoo#257986

#attendance#overtime#timezone#stability

Branch: saas-18.4

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_co_dian: correct sts namespace for DIAN Credit Note

PR #114003

Enterprisesaas-18.4l10n_co_dianMEDIUM

This change corrects the XML namespace used when sending Colombian credit notes to DIAN. It prevents validation errors during submission and helps ensure these documents are accepted correctly.

Original PR description

Issue:
Incorrect `sts` namespace raises several issues when sent to dian

Steps to reproduce:
- On a Colombian company
- Create a credit note
- Send to DIAN

Current Behavior:
- Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`
while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures`

Expected Behavior:
- Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`.

It was forgotten that Credit Note were part of the Invoices in the last refactor.

As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test.

opw-6077050

Forward-Port-Of: odoo/enterprise#113643

#colombia#dian#credit note#xml#electronic invoicing

Branch: saas-18.3

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_co_dian: correct sts namespace for DIAN Credit Note

PR #113985

Enterprisesaas-18.3l10n_co_dianMEDIUM

This fix corrects the XML namespace used when sending Colombian credit notes to DIAN. It prevents submission errors by ensuring the document uses the expected structure, improving reliability for users who issue credit notes.

Original PR description

Issue:
Incorrect `sts` namespace raises several issues when sent to dian

Steps to reproduce:
- On a Colombian company
- Create a credit note
- Send to DIAN

Current Behavior:
- Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`
while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures`

Expected Behavior:
- Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`.

It was forgotten that Credit Note were part of the Invoices in the last refactor.

As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test.

opw-6077050

Forward-Port-Of: odoo/enterprise#113643

#colombia#DIAN#credit note#XML#invoicing

Branch: saas-18.2

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] documents_account: fix xml document preview with embedded pdf

PR #113845

Enterprisesaas-18.2documents_account

This update fixes a display issue in Documents where certain XML email attachments that can be previewed as PDF were opening in two preview panes at once. Users now see a single correct preview, improving readability and avoiding confusion when reviewing incoming documents.

Original PR description

**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…

**Steps to reproduce:**
- Install documents_account
- Set up alias to catch incoming mails
- Receive a mail with xml attachement which can be previewed as pdf
- Go to Documents app
- Click on the document preview
- Preview is split in two iframes, both with the same content (pdf)

**Issue:**
Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`.
```
<iframe t-if="state.file.isPdf" ...
<iframe t-if="state.file.isText" ...
```

It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file.

**Fix:**
Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`.

Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: 
`<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">`
which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b

related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450

opw-6018536

Forward-Port-Of: odoo/enterprise#112041

#documents#preview#attachments#pdf#xml

Branch: master

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] planning_field_service: geolocation service test failures

PR #114709

Enterprisemasterplanning_field_service

This update stabilizes the geolocation service tests used by Field Service planning. It reduces unnecessary test work so the checks run consistently and no longer fail at random, which helps keep development and releases more reliable.

Original PR description

This commit fixes the undeterministic test failures for the geolocation service. We reduce the [workload](https://github.com/odoo/enterprise/blob/master/planning_field_service/static/src/services/field_service_geolocation_service.js#L26) of the `startWatch` method by mocking the `has_group` calls.

Forward-Port-Of: odoo/enterprise#114572

#testing#stability#field service#geolocation

[FIX] various: update query counters

PR #114708

Enterprisemastermailaimarketing_automation

This change updates several internal counters used by mail and related performance checks so they match the expected system state. It helps ensure automated checks stay reliable and prevents incorrect error handling when rendering content with a missing field.

Original PR description

>
> Update various (main mail-related) counters according to runbot state.

Forward-Port-Of: odoo/enterprise#114603

#performance#testing#mail#stability

Branch: 19.0

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] sale_subscription: align portal preview lines with tax totals

PR #114088

Enterprise19.0sale_subscription

The subscription portal now shows only the product lines that are actually invoiceable. This keeps the displayed lines consistent with the tax totals at the bottom, reducing confusion for customers reviewing their subscription details.

Original PR description

Previously, the portal view for subscriptions displayed all un-collapsed products from the sales order, ignoring whether they were actually invoiceable lines. This caused a visual mismatch where the displayed lines did not correspond to the calculated tax totals at the bottom of the view. This commit updates the visibility logic to ensure that product lines are only included if they are invoiceable.

task-6128619

#portal#subscriptions#tax totals#invoiceable lines

[FIX] delivery_sendcloud: Adding sendcloud partner key to request

PR #114540

Enterprise19.0delivery_sendcloudMEDIUM

This update adds an Odoo partner key to Sendcloud requests so Sendcloud can recognize traffic coming from Odoo and continue supporting the older API during their transition. It helps avoid interruptions for customers while Sendcloud phases in their new API version.

Original PR description

Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api.

Future work will be done to upgrade our module and support the v3. API key.

Forward-Port-Of: odoo/enterprise#114441

#delivery#shipping#sendcloud#api compatibility

[FIX] l10n_mx_edi: fixing rounding test

PR #114320

Enterprise19.0l10n_mx_edil10n_mx_edi_pos

This update corrects a test for Mexican electronic invoicing so it matches the current rounding behavior again. It helps prevent false failures in the validation checks used to keep this localization working properly.

Original PR description

https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed.
This break the test modified in this PR.

opw-5963855

Forward-Port-Of: odoo/enterprise#114081

#mexico#e-invoicing#testing#rounding

Branch: 18.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] account: tax-included price recomputation on branches

PR #260441

Core18.0accountMEDIUM

Invoices created in branch companies now recalculate product prices correctly when a fiscal position changes the tax setup. This ensures prices no longer stay inflated with tax included, which helps keep branch billing accurate and consistent.

Original PR description

When operating in a multi-company branch environment, the unit price of
a product with price-included taxes is not correctly recalculated when
applying a fiscal position.

Steps to reproduce:
- Create a tax that is included in the price (e.g., 10% incl).
- Assign this tax to a product (e.g., Product A).
- Create a fiscal position that maps this 10% tax to a different tax.
- Create a branch (child company) of your main company.
- Create an invoice in the new branch using the fiscal position and add
  an invoice line for Product A.

Issue: The unit price of the product on the invoice line remains the
full tax-included amount rather than being reduced to exclude the
original 10% tax.

opw-5931302

Forward-Port-Of: odoo/odoo#256897

#invoice#taxes#fiscal-position#multi-company#branch

Branch: 17.0

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_cz_reports_2025: remove country code from vat number in vies summary report xml

PR #113083

Enterprise17.0l10n_cz_reports_2025MEDIUM

The VIES Summary Report XML export now removes the country prefix from customer VAT numbers. This ensures the file matches the official Czech format and helps prevent validation issues when submitting the report.

Original PR description

**Steps to reproduce:** - Install the `l10n_cz_reports` module and switch to a `CZ Company` - Create an invoice for a customer with a VAT number, add a product, and set the Transaction Code (enable…

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

#vat#vies#xml#czech-localization#reporting

Rows:Rows per page:

10 25 50 100

3 / 3Page 3 of 3 · 243 days total