Daily updates from Odoo
Monday, April 6, 2026
24 changes
6 changes
Resolved issues and error corrections
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
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
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
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 -…
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 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
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) -…
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
9 changes
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
2 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from viewing detailed ticket information when analyzing data grouped by employee, manager, or department. The fix ensures the reporting system correctly translates field names, resolving an error related to data validation within the ticket model. This improves the accuracy and usability of the ticket analysis reporting feature.
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 resolves an issue where amounts weren't displayed correctly in Danish balance sheet and profit & loss reports when child lines were hidden. The changes simplify report formatting by using account names as sublines and ensure accurate translations for Danish and English versions. This improves the accuracy of financial reporting for Danish businesses.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113069 Forward-Port-Of: odoo/enterprise#112430
2 changes
Resolved issues and error corrections
This update resolves an issue where the Ticket Analysis graph and pivot features would fail when grouping by Employee, Manager, or Department. The fix ensures that the reporting fields are correctly mapped to the underlying ticket data, allowing users to accurately 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 corrects a display issue where archived email templates were incorrectly appearing in the 'Refuse Applicant' wizard. The fix ensures that only active email templates are shown, improving the user experience and preventing confusion. This was caused by a technical update to how Odoo handles related data.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.
Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template" and click on 'Search More'
7. Observe available templates
Issue:
-------
1. Archived email templates are displayed in the Email Template field.
2. If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template
Cause:
----------
1. After the [refactoring of Many2oneField](https://github.com/odoo-dev/odoo/commit/3670f78be767396f322ff3ebf068af5c2f547b36) to use dynamicInfo.context,
now ensures that global context keys propagate to relational fields.
The archive_applicant method opens the refuse wizard with **'active_test': False**
in the context to allow refusing archived applicants. As a result, this context is now
applied when fetching the email templates, causing archived records to be included in
the search results.
https://github.com/odoo/odoo/blob/7966fae0c1fd7cfb6023efc0c274b8b395bf862f/addons/web/static/src/views/fields/relational_utils.js#L313-L321
2. Moreover, the `_compute_send_mail` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L29-L33
Solution:
-----------
- Pass `context="{'active_test': True}"` to the `template_id` field to ensure
archived templates are excluded by default, while still allowing users
to manually search for them if needed.
- Update `_compute_send_mail` to ensure only active templates are
automatically assigned.
**NOTE:**
Issue 1 only exists till saas-18.4. From saas-18.4, email templates are fetched using [search_read](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/addons/mail/static/src/core/web/mail_composer_template_selector.js#L33-L46) without passing
the context. Additionally, [search_read removes 'active_test'](https://github.com/odoo/odoo/blob/90db6b197edb93814d980345af01c56c2b6e553e/odoo/orm/models.py#L5780-L5785)
before formatting the result, so archived records are not included.
opw-5974244
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257286
Forward-Port-Of: odoo/odoo#2511861 change
Resolved issues and error corrections
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format in web_studio. The fix prevents the system from attempting to process invalid XML data, ensuring a smoother user experience. This improves report creation stability.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#112400 Forward-Port-Of: odoo/enterprise#88613
4 changes
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 ensures accurate financial reporting for orders processed through the Urban Piper integration.
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 resolves an error that occurred when analyzing tickets in the reporting section, specifically when grouping by employee, manager, or department. The fix ensures that the reporting system correctly translates data fields, preventing a server error and allowing users to accurately view related 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 fixes an error where child companies were incorrectly inheriting the tax return journal setting from their parent company. This ensured that each company had its own, accurate tax return journal configuration, preventing reporting discrepancies. Ticket 114344 details this correction.
Original PR description
The objective of this pull request is to show that when the parent company has the tax return journal (account_tax_return_journal_id) set up but the child company does not, then the child company will also have the same tax return journal (account_tax_return_journal_id) set up, but it is incorrect because it is a different company. Ticket: 114344
This update resolves a display issue in the Danish balance sheet and profit & loss reports. It ensures that amounts are always shown, even when child lines are hidden due to zero values, improving report clarity and accuracy for Danish accounting practices.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113079 Forward-Port-Of: odoo/enterprise#112430