Daily updates from Odoo
Monday, April 6, 2026
10 changes · saas-19.1
Enhancements to existing features
This update quietly displays a warning notification within WhatsApp channels when a new template is sent. This prevents distracting pop-ups, especially when multiple templates are used, ensuring a smoother experience for users and reducing unnecessary interruptions.
Original PR description
When a different user sends a WhatsApp template, a warning notification is posted in the active channel indicating that future replies will be moved to a new chat. This notification is now posted silently to avoid unnecessary popups, especially when templates are sent in bulk to multiple contacts with ongoing conversations. Forward-Port-Of: odoo/enterprise#112961
Resolved issues and error corrections
This update ensures that account moves are automatically created when closing a POS session containing Urban Piper future orders (orders with a delivery date). Previously, these orders were excluded, preventing proper accounting record generation. This fix resolves a technical issue impacting financial reporting accuracy.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#113075 Forward-Port-Of: odoo/enterprise#111137
This update fixes a problem where the Ticket Analysis reporting feature would fail when grouping data by Employee, Manager, or Department. The fix ensures that the reporting fields are correctly mapped to the underlying ticket data, allowing users to accurately view and analyze their helpdesk tickets.
Original PR description
Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department. ### **Steps to reproduce** 1) Install helpdesk_timesheet with demo data 2)…
Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department.
### **Steps to reproduce**
1) Install helpdesk_timesheet with demo data
2) Go to Timesheet > Reporting > Ticket Analysis
3) Set group by to Employee
4) Click on any graph bar or pivot cell
### **Error:**
`ValueError: Invalid field helpdesk.ticket.employee_id in condition ('employee_id', '=', 1)`
Root Cause:
The `helpdesk.ticket.report.analysis` model includes specific fields such as `employee_id`, `department_id`, and `employee_parent_id` (see [1]) that are defined for reporting purposes but do not exist on the `helpdesk.ticket` model. When a user clicks a data point to view related tickets, the reporting view passes the current domain directly to the ticket list view. Because `helpdesk.ticket` lacks these fields, the ORM fails to validate the domain, resulting in a server error.
[1]- https://github.com/odoo/enterprise/blob/8d16b647431985dd7c216ae39eea6ca050e04b46/helpdesk_timesheet/report/helpdesk_ticket_report_analysis.py#L15-L17
### **Fix:**
This commit introduces a mixin to intercept the openView call. The mixin maps reporting-specific fields to valid relational paths on the ticket model `(for example, employee_id is transformed into user_id.employee_id)`. This ensures that the domain generated from the report model is compatible with the target ticket model.
**opw-5931273**
Forward-Port-Of: odoo/enterprise#108503This update streamlines the ActivityWatch installation process by adapting instructions for new installers and providing clearer checks for successful server setup. Additionally, the timesheet assistant has been enhanced with improved rule data, clearer field labels, and more informative event display, resulting in a smoother user 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
This update resolves a bug that prevented users from correctly reverting changes to a product's 'Recurring' subscription setting when confirmed sales orders were associated. The fix ensures that changes are reliably reverted, preventing incorrect subscription statuses and improving data consistency. This update impacts subscription products.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server. Forward-Port-Of: odoo/enterprise#111725 Forward-Port-Of: odoo/enterprise#110877
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 system. This improves order tracking and reporting for self-service POS operations.
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
This update corrects an issue where creating new lines on a purchase order would trigger a technical error. The problem stemmed from a misconfiguration during a code update, preventing the correct setting of the 'date_promised' field. This fix ensures purchase orders can be created and managed correctly, improving the purchasing process.
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) -…
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
This update fixes a potential issue where unauthorized content could be displayed in dynamic website snippets, particularly in single-record mode. It now ensures that only snippets linked to valid website snippet filters are used, and unpublished website records are no longer fetched. This enhances security and data integrity.
Original PR description
Forward-Port-Of: odoo/odoo#257208
This update fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct number of units (packs of 6) is shown on the delivery slip, resolving a discrepancy between ordered and delivered quantities. This improves accuracy in inventory tracking.
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 -…
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#249779This update corrects a vulnerability where users could unexpectedly change tax settings within a Point of Sale (POS) session, leading to discrepancies between receipts and invoices. The change adds a safeguard to prevent these modifications, ensuring data consistency and accuracy in POS transactions. Related tests have been updated to reflect this fix.
Original PR description
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in…
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py. After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open. This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start. For example, changing this setting mid-session may differences between POS receipts and backend invoices. By adding `price_include_override` to the forbidden fields, the UserError can properly be raised. Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this. Related ticket: opw-6042367 Forward-Port-Of: odoo/odoo#256512 Forward-Port-Of: odoo/odoo#254487