Daily updates from Odoo
Tuesday, June 2, 2026
20 changes · 19.0
Resolved issues and error corrections
This update resolves an issue where employees with overlapping contracts would incorrectly trigger a 'Duplicate Payslip' warning. The change limits the warning check to only consider payslips with the same version, ensuring accurate payroll processing for employees with multiple contracts within the same month.
Original PR description
If an employee has a contract that ends in the middle of the month and another contract starts in the same month, the two payslips that are created for the month trigger the "Duplicate Payslip" warning, even though they use different version IDs. This commit limits the search domain for the duplicate payslips to only consider payslips with the same version ID. task-6226391
This update resolves an issue where orders exceeding a weight threshold triggered errors when using the Sendcloud delivery method in e-commerce. The fix ensures that the system accurately processes multi-package orders based on weight, preventing errors and improving order fulfillment. This improves the reliability of the e-commerce shipping process.
Original PR description
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud…
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud delivery method - make it available in e-commerce - Create a 150kg product and publish it - Go to e-commerce - Add the product to cart - Checkout the cart > Traceback Cause ----- We retrieve the order's weight through the context. https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108 If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128 If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow). https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69 ----- Ticket: opw-6210398
This update resolves an issue where custom POS modules could unexpectedly block login. By introducing a new check within the POS system, we ensure that login only fails when a cashier is intentionally set to prevent access, providing a smoother and more reliable user experience for POS operations.
Original PR description
When a custom module patches `setCashier` without returning a value, the login check in `select_cashier_mixin` received `undefined` (falsy), causing the login flow to abort even though the cashier was set correctly. Introduce a dedicated `canLoginCashier` hook on `PosStore` that controls whether a login attempt should proceed. The mixin now calls this method before `setCashier`, decoupling the login guard from `setCashier`'s return value entirely. Custom modules that need to block login should override `canLoginCashier` instead of relying on `setCashier` returning `false`. opw-6247190
This update ensures that the l10n_id_reports module can be properly translated within Odoo. By adding the module to the Weblate configuration file, the system now recognizes and supports translation workflows for this specific reporting module, improving localization capabilities.
Original PR description
Enable translation management by adding the module entry to .weblate.json. task-6239169
This update resolves a test failure that occurred when the demo data was installed. The fix ensures that simulation offers are hidden by applying a filter, preventing errors during testing and improving the stability of the salary payroll module. This ensures accurate simulation runs.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575
A test was failing due to a limitation in how the POS system loads partner data. This update corrects the test to ensure it functions correctly with demo data, preventing a disruption in the POS functionality. This ensures the POS system operates as expected for all users.
Original PR description
**Issue:** `test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983
This update fixes an issue where the project template dropdown in demo mode had a poorly designed layout, making it difficult to read. The fix removes a styling element that caused text to overlap, ensuring a consistent and user-friendly experience for all users, including demo users.
Original PR description
Steps to reproduce: == Login as demo/onboarding user Open Project app Click on New Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191
This update enhances the usability of asset analytics by enabling multi-editing of the analytics distribution field, mirroring the functionality available for journal items. This change simplifies the process of updating asset analytics data, improving efficiency for users.
Original PR description
This commit fixes the multi-edit of analytics distribution field in assets form view. The multi-edit option was added to the analytics distribution widget, same as in the journal items. task-6218188
This update fixes a technical issue that caused a traceback when attempting to mark workorders as done in certain scenarios, specifically when no workorders were open. The fix ensures the system handles empty recordsets gracefully, preventing errors and maintaining stability.
Original PR description
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety…
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 Inside button_finish, it retrieves all open workorders and marks them as done: - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 - mark them as done: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678 Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 -> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback. opw-6239910 Forward-Port-Of: odoo/enterprise#118403
This update resolves an issue where orders placed via mobile self-order with 'Pay After Meal' and online payment were not being sent to the kitchen for preparation. The fix ensures that all orders, regardless of payment type, are now correctly transmitted to the preparation display, improving order workflow efficiency.
Original PR description
pos* = pos_self_order_preparation_display, pos_online_payment_self_order_preparation_display Configuration: -------------- - Restaurant Mode - Self-Order Mode: "QR + Ordering" - Service At: Table - Pay after meal (Online Payment) Issue: ------ Orders created via mobile self-order using "Pay After Meal" + online payment were not appearing in the Preparation Display. Steps to Reproduce: ------------------- 1. Create an order from mobile self-order. 2. Open the restaurant POS, the order is visible there, but it does not appear on the preparation display. Cause: --------------- - The system only sent paid orders to the kitchen when online payment is set, skipping pay-after-meal case. Fix: ------------ - Updated logic to send all orders to the kitchen when “Pay After Meal” is selected, Task: 5929555 Forward-Port-Of: odoo/enterprise#107129
This update resolves an issue where Odoo was incorrectly flagging service invoices as requiring an Incoterm, even though this requirement doesn't apply to service products. The fix ensures that service invoices are processed correctly when exporting to the tax agency, preventing export errors.
Original PR description
With l10n_gt_edi: - Create an invoice with a partner without a country (in l10n_gt this is considered an export invoice) and a service product. When trying to export the invoice to the tax agency, the following alert is triggered: Incoterm is required on export invoice with goods product but it's currently missing However, service products do not require incoterm configuration. opw-6170409
This update addresses a requirement from the Peruvian tax authority (SUNAT) regarding delivery guides. Customers using the l10n_pe_edi_stock module now *must* include a 'carrier handover date' field to avoid validation errors. The update automatically handles this by reusing the existing departure start date for public transport deliveries, and provides a helpful message to users on older versions to update the module.
Original PR description
SUNAT R. S. N° 000108-2026/SUNAT and the GRE validation rules published on 2026-06-01 add field 34 "Fecha de entrega de bienes al transportista" (cac:LoadingTransportEvent/cbc:OccurrenceDate). It is required, and rejected with error 3617 when absent, only when the transport modality is '01' (public transport). Enforcement started 2026-06-01, so affected customers can no longer submit their delivery guides.
In our implementation the departure start date is equivalent to this date, so we reuse it instead of adding a new field. The node is gated to public transport to match the validation rule and avoid emitting it on private transport ('02') guides.
Because the new node only ships with this module version, customers on an older version keep hitting error 3617 from SUNAT. Detect that code in the SUNAT response and store an actionable message asking the user to update the module, instead of surfacing the raw rejection.
task-6266662
Forward-Port-Of: odoo/enterprise#119038This update corrects a minor visual issue where an unnecessary space appeared at the top of payslips. This ensures a cleaner and more professional appearance for payroll documents, improving the user experience. The fix was implemented to maintain consistent formatting and readability.
Original PR description
There was an extra space useless on top of payslips because there was an extra field "issue" that should'nt be there Task: 6268680
This update resolves an issue where reports downloaded in Safari (specifically with the German language setting) were generating incorrect filenames. The problem stemmed from a formatting error in the date-based filename generation process, which failed to handle certain date formats. This change ensures reports download with the correct, intended filenames.
Original PR description
**STEP TO REPRODUCE** 1. On safari 2. Switch language to German. 3. On the general Ledger, select a custom date range. 4. Download the pdf/xslx 5. Notice the file have the name `example.com` instead of the intented name. **CAUSE** Since 19.0, we use the date to generate the file name. There is a regex used to format the date range, but it doesn't catch some date format like `DD.MM.YYYY`, which some localisation used. In such case, we use a string which contains a `\n` character to build the filename. This doesn't work on safari, leading to the file defaulting to `example.com` opw-6194841
This update fixes an issue where automation rules using dotted field paths for user assignment in activity creation failed to display the correct user information. The change utilizes a mapping approach, mirroring a previous fix in the mail module, to correctly handle relational field chains and ensure accurate user assignment.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `ai` and `contacts` modules 2. Create an automation rule on Contact model: * Trigger: On Creation * Action To Do: Execute AI Action…
Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
* Trigger: On Creation
* Action To Do: Execute AI Action
* Add a server action tool with 'Create Next Activity' action
* Set Activity User Type to Dynamic
* Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user
Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths
Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed
Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module
opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530This update resolves a bug in the general ledger report within Odoo 19.0 that could cause errors when expanding collapsed lines based on a threshold setting. The change ensures the report functions correctly by adjusting how data is filtered, preventing index errors. This fix only applies to Odoo 19.0.
Original PR description
Before this commit, when expanding a line collapsed by the `prefix_groups_threshold` setting could cause an index error when in the case where `lines == []` here https://github.com/odoo/enterprise/blob/ebcbea05bf5e43c9940c32cb0140c3e5cb1ba39e/account_reports/models/account_general_ledger.py#L381 This commit changes the forced_domain such that it uses `display_name` instead of `name` at https://github.com/odoo-dev/enterprise/blob/f4a5d104c479d00101f1381e9cdc31cb1a8d7bf7/account_reports/models/account_report.py#L6023 Steps to reproduce: New 19.0 DB Install accountant Create a journal entry for a few different accounts Activate developer mode Go to the general ledger and click the settings/gear icon Lower the threshold to something small, like 2 Go back to the report and attempt to open the now collapsed line and see error **Only affects 19.0, `prefix_groups_threshold` does not exist in higher versions** opw-6231127
This update fixes a bug in the helpdesk rating dashboard. Previously, ratings created late in the day weren't accurately reflected in search results. Now, the system uses the current date and time for searches, ensuring ratings from the last seven days are correctly displayed.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905
This update optimizes the visual styling of the Odoo Enterprise home menu to improve website loading speed. By replacing complex CSS selectors with CSS variables, the system now performs more efficiently, leading to a faster and smoother user experience. This change focuses on performance enhancements.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage.
This update corrects a reporting issue where combo products incorrectly appeared in the 'Invoiced Not Delivered' report even after full delivery. The fix ensures that only actual delivered items are listed, improving the accuracy of this key accounting report. This prevents duplicate reporting and provides a more reliable view of invoiced stock.
Original PR description
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps…
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps to reproduce:** 1. Create a combo product bundling two storable items. 2. Sell the combo on a sale order, confirm and invoice it. 3. Deliver every combo item. 4. Open Accounting > Review > Invoiced Not Delivered. **Current behavior:** The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information. **Expected behavior:** The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered. **Cause of the issue:** A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where `qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever. **Fix:** Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct. opw-6215110
This update fixes a problem where DHL shipping labels weren't correctly using the specified template (6x4 A4). The code now maps the incorrect label formats to the correct DHL API values, ensuring labels are generated in the desired dimensions. This prevents incorrect label sizes and improves shipping accuracy.
Original PR description
Issue ----- Labels generated with DHL do not respect the template (dimensions) set on the delivery method. Steps to reproduce ----- - Set up DHL - set label template as 6X4_A4_PDF - Create a delivery…
Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.
Steps to reproduce
-----
- Set up DHL
- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery
> The generated label is in 8x4 inch format instead of 6x4 full page
Explanation
-----
All info below was found in DHL's API doc from the following YAML file
https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml
There are 2 issues with the current implementation regarding the label format.
1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:
- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001
(values taken from the excerpt below)
```
templateName:
description: >-
Please enter DHL Express document template name.
<BR> Sample Transport label
templates:<BR> ECOM26_84_A4_001
<BR> ECOM26_84_001 - default<BR>
ECOM_TC_A4<BR> ECOM26_A6_002<BR>
ECOM26_84CI_001<BR> ECOM26_84CI_002 - supported
single customer barcode<BR> ECOM26_84CI_003 -
to be used if customer barcodes are used<BR>
ECOM_A4_RU_002<BR>
ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
[...]
type: string
maxLength: 25
example: ECOM26_84_001
```
[...]: additional info unrelated to labels (useful only for other `typeCode` values)
Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.
- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001
Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is 101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2
2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)
```
fitLabelsToA4:
description: >-
To print respective Transport Label and Waybill document into
A4 margin PDF.<BR> Note:
ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
template. <BR> This option is applicable only
for PDF encodingFormat selection.<BR> false:
Transport Label and Waybill document will use default margin
settings (default behavior) <BR> true:
Transport Label and Waybill document will print into A4 margin
PDF
type: boolean
example: false
```
-----
Ticket:
opw-6148713