Odoo Changelog — 2026-04-06

Monday, April 6, 2026

6 changes · saas-19.2

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_co_dian: fix commercial event XML generation

Enterprisesaas-19.2l10n_co_dianMEDIUM

This update corrects errors in the generation of XML files for commercial events, ensuring accurate data transmission to the Dian authority. The fix resolves issues with incorrect naming conventions and UUID extraction, preventing rejection of submitted documents. This ensures compliance and proper processing of commercial events.

Original PR description

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went…

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls
_add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g.  "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash:

Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE.

_dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's.

We now render commercial events like how invoices are rendered.

[1] odoo/enterprise#107170

opw-6065701

Forward-Port-Of: odoo/enterprise#112973
Forward-Port-Of: odoo/enterprise#112812

#accounting#tax#compliance

[FIX] timesheet_grid: revamp installation wizard

PR #113098

Enterprisesaas-19.2timesheet_gridMEDIUM

This update streamlines the installation process for the ActivityWatch timesheet module, providing clearer instructions and improved verification steps. Additionally, the timesheet assistant has been enhanced with better rule data, clearer field labels, and more informative event display, resulting in a more user-friendly experience.

Original PR description

This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running.

It also provides a few other fixes related to the assistant in general.

Task-6042434

Forward-Port-Of: odoo/enterprise#112127

#timesheet#installation#assistant#activitywatch

[FIX] pos_self_order: fix tracker info for self order

PR #257169

Coresaas-19.2pos_self_order

This update resolves an issue where tracker numbers weren't being displayed correctly in the order details after completing a self-order kiosk transaction. The fix ensures that the tracker number is accurately recorded and visible when reviewing the order in the backend. This improves the clarity and accuracy of order tracking for staff.

Original PR description

Step to reproduce:
- install "pos_self_order"
- have a kiosk type pos, with "service at" = "table"
- start kiosk and fulfill a order
- on confirmation page, add a tracker number for that order.
- go to backend and open that order

Observation:
- check "order name" in "Extra info" page, we do not get tracker number

Cause:
- After this commit [1], the tracker data is overridden by next if blocks
- hence the data is lost.

Fix:
- fix the condition.

[1] https://github.com/odoo/odoo/commit/c3ea329f1dce44c668e4907fa98cb5104ed11741

opw-5975717


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

Forward-Port-Of: odoo/odoo#253304

#pos#kiosk#order tracking

[FIX] stock: show correct quantities on delivery slip

PR #257552

Coresaas-19.2stockMEDIUM

This update fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct quantity (5) is shown when printing delivery slips with items packaged in 'packs of 6', resolving a discrepancy between ordered and delivered amounts.

Original PR description

Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity.

## Steps to replicate:
- Install Purchase and Inventory with demo data
- Settings > Enable 'Units of Measure & Packagings' and 'Packages'
- Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor.
- Create new RFQ with the same vendor for 'Desk pad' having quantity 10
- Confirm RFQ > Go to receipt > Details
- Create and Set Destination Package to 
    - LOT A 5 pack of 6 
    - LOT B 5 pack of 6
- Validate Delivery Order and Print the Delivery Slip

## Observed Behavior:
Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect.

The correct quantity ordered and delivered should be 5 (Pack of 6).

## Root cause:
This unintentional behavior occurs after commit [1].

When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging.

As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed.

Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5.
[2]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945 
[3]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88
## Solution:
Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly.

**Before:**
<img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" />
**After:**
<img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" />

[1]:
https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28 

opw-5930343

Forward-Port-Of: odoo/odoo#256849
Forward-Port-Of: odoo/odoo#249779

#inventory#delivery#packaging

[FIX] website, website_sale: restrict access to content in dynamic snippet config

PR #257707

Coresaas-19.2websitewebsite_saleSECURITY

This update enhances the security of dynamic website content by restricting access to snippet configurations in single-record mode. Specifically, it prevents unauthorized access to website content and ensures that unpublished website records aren't used when rendering snippets, improving overall system stability.

Original PR description

Forward-Port-Of: odoo/odoo#257208

#security#website#snippets

[FIX] purchase_stock: set date_promised new purchase line

PR #257778

Coresaas-19.2purchase_stock

This update corrects an issue where new lines added to purchase orders were causing a system error. The problem stemmed from a minor coding oversight during a recent update, preventing the correct setting of the 'date_promised' field. This fix ensures that purchase order lines are properly created and processed, improving order management.

Original PR description

How to reproduce:
- Install both Purchase and Inventory application
- Create a PO with Vendor X (with a purchase line to be able to create a picking but the  purchase line in itself will not matter)
- Confirm Order > Receive
- Add a new move line with any product and atleast one quantity
- Validate
- Try to access or create any PO with the Vendor X

The problem:
A traceback is shown

Cause:
When accessing or creating a new PO with Vendor X, we compute his
`on_time_rate`. During this computation, we filter the moves using their
purchase line's `date_promised`
https://github.com/odoo/odoo/blob/7e60b3f3da2d7991220b164046a179b224384f9e/addons/purchase_stock/models/res_partner.py#L57

Commit [1] altered the behavior when creating new lines in a picking and a
slight oversight was made while forward-porting :
https://github.com/odoo/odoo/blob/7e60b3f3da2d7991220b164046a179b224384f9e/addons/purchase_stock/models/purchase_order_line.py#L102-L105
This makes it so `date_promised` is not set for these new lines and stays
`False`. Calling `.date()` on a bool creates a traceback

That said, the compute method should also be more robust since the field
`date_promised` is not required.

opw-6082456

[1] https://github.com/odoo/odoo/commit/52da6f77f7bf053b448f602196175b1354f70702

Forward-Port-Of: odoo/odoo#257341

#purchase#order#inventory

When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls _add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g. "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash: Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE. _dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's. We now render commercial events like how invoices are rendered. [1] odoo/enterprise#107170 opw-6065701 Forward-Port-Of: odoo/enterprise#112973 Forward-Port-Of: odoo/enterprise#112812

This PR revamps the ActivityWatch installation wizard to adapt the instructions to the new installers, as well as providing more ways to check that the server is successfully installed and running. It also provides a few other fixes related to the assistant in general. Task-6042434 Forward-Port-Of: odoo/enterprise#112127

Step to reproduce: - install "pos_self_order" - have a kiosk type pos, with "service at" = "table" - start kiosk and fulfill a order - on confirmation page, add a tracker number for that order. - go to backend and open that order Observation: - check "order name" in "Extra info" page, we do not get tracker number Cause: - After this commit [1], the tracker data is overridden by next if blocks - hence the data is lost. Fix: - fix the condition. [1] https://github.com/odoo/odoo/commit/c3ea329f1dce44c668e4907fa98cb5104ed11741 opw-5975717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253304

Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity. ## Steps to replicate: - Install Purchase and Inventory with demo data - Settings > Enable 'Units of Measure & Packagings' and 'Packages' - Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor. - Create new RFQ with the same vendor for 'Desk pad' having quantity 10 - Confirm RFQ > Go to receipt > Details - Create and Set Destination Package to - LOT A 5 pack of 6 - LOT B 5 pack of 6 - Validate Delivery Order and Print the Delivery Slip ## Observed Behavior: Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect. The correct quantity ordered and delivered should be 5 (Pack of 6). ## Root cause: This unintentional behavior occurs after commit [1]. When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging. As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed. Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5. [2]- https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945 [3]- https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88 ## Solution: Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly. **Before:** <img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" /> **After:** <img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" /> [1]: https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28 opw-5930343 Forward-Port-Of: odoo/odoo#256849 Forward-Port-Of: odoo/odoo#249779

How to reproduce: - Install both Purchase and Inventory application - Create a PO with Vendor X (with a purchase line to be able to create a picking but the purchase line in itself will not matter) - Confirm Order > Receive - Add a new move line with any product and atleast one quantity - Validate - Try to access or create any PO with the Vendor X The problem: A traceback is shown Cause: When accessing or creating a new PO with Vendor X, we compute his `on_time_rate`. During this computation, we filter the moves using their purchase line's `date_promised` https://github.com/odoo/odoo/blob/7e60b3f3da2d7991220b164046a179b224384f9e/addons/purchase_stock/models/res_partner.py#L57 Commit [1] altered the behavior when creating new lines in a picking and a slight oversight was made while forward-porting : https://github.com/odoo/odoo/blob/7e60b3f3da2d7991220b164046a179b224384f9e/addons/purchase_stock/models/purchase_order_line.py#L102-L105 This makes it so `date_promised` is not set for these new lines and stays `False`. Calling `.date()` on a bool creates a traceback That said, the compute method should also be more robust since the field `date_promised` is not required. opw-6082456 [1] https://github.com/odoo/odoo/commit/52da6f77f7bf053b448f602196175b1354f70702 Forward-Port-Of: odoo/odoo#257341