Odoo Changelog — 2026-07-07

Tuesday, July 7, 2026

6 changes · 19.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] mrp_workorder:scan product barcode shopfloor

Enterprise19.0mrp_workorderMedium

Fixed an issue where scanning a component product barcode on the shopfloor did nothing when that component was tied to a manufacturing operation. Operators can now scan these products as expected, reducing interruptions and manual follow-up during production.

Original PR description

When scanning a product barcode in the shopfloor, it would not simulate
a click on the product if the corresponding BoM line was linked to an
operation.

Steps to reproduce:
-------------------
* Create a BoM for product A with a BoM line for product B and link it
  to any operation.
* Create a WO for product A and confirm it
* Open the shopfloor with the WO and scan the barcode of product B
> Observation: Nothing happens

Why the fix:
------------
We simulate the onClick for the product even if the move is not marked
manual_consumption.

opw-6268665

#shopfloor#barcode#manufacturing#work orders

[FIX] knowledge: show embedded views when printing an article

PR #121210

Enterprise19.0knowledgeMedium

Knowledge articles with embedded kanban, calendar, or map views now print and export to PDF correctly. This prevents blank PDFs and ensures users can share complete article content as expected.

Original PR description

When a Knowledge article embeds a kanban, calendar or map view and the user prints it or exports it to PDF, the view is missing and the printed page is blank. The Knowledge print stylesheet hides…

When a Knowledge article embeds a kanban, calendar or map view and the user prints it or exports it to PDF, the view is missing and the printed page is blank.

The Knowledge print stylesheet hides those embedded views in print mode. The rule was introduced with the print feature under the selector `.o_knowledge_embedded_view > .o_kanban_view`, but `.o_knowledge_embedded_view` is emitted nowhere in the templates or components, so the rule matched nothing and the embedded views were always printed. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rescoped the print rules and retargeted the selector to the real wrapper as `[data-embedded="view"] .o_kanban_view`. That selector matches, so the views are now hidden and the printed article is blank.

Remove the rule from `knowledge_print.scss` so embedded views render again in print mode, restoring the behavior that held since the print feature was introduced.

Steps to reproduce:
1. Open Knowledge and create a new article.
2. Click Build an Item Kanban, type a name and click Insert.
3. Add an item with Quick add so a card appears in the kanban.
4. Open the article options menu and click Download PDF.

=> The embedded kanban view is missing and the PDF is blank.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6299703)
opw-6299703

[FIX] sale_lazada: don't sync order item statuses

PR #122851

Enterprise19.0sale_lazadaMedium

Lazada order imports no longer adjust individual item quantities based on item-level cancellation statuses. This prevents delivered orders from failing to sync when Lazada reports an exceptional item status after delivery.

Original PR description

Lazada stores order statuses at the item level. When an item is canceled, we mirrored this by decreasing the ordered quantity on the sale order line. But if the item was already delivered, decreasing the quantity below the delivered amount is forbidden and raises a `UserError`, which aborts the whole order sync:

```python
  File ".../sale_stock/models/sale_order_line.py", line 420, in _update_line_quantity
    raise UserError(_('The ordered quantity of a sale order line cannot be decreased below the amount already delivered. [...]'))
```

In practice, item-level statuses only differ from the order status in exceptional cases. Stop syncing statuses at the item level and assume the entire order shares a single status, which avoids the quantity decrease and the resulting traceback.

opw-6267730

#Lazada#order sync#sales orders

[FIX] l10n_hk_hr_payroll: Payment in Lieu of Notice

PR #123023

Enterprise19.0l10n_hk_hr_payrolltest_l10n_hk_hr_payroll_accountMedium

This fixes Hong Kong payroll calculations for payment in lieu of notice when an employee has not worked a full 12 months. The calculation now uses the contract start date to determine the relevant days and months, helping produce more accurate final payroll amounts and adding tests for special cases.

Original PR description

Currently, the calculation of the payment in lieu of notice is assuming the employee worked a whole 12 months prior to it being paid.
This is of course not always going the be case, and when it happens our calculation is often incorrect.

We update the salary rule to calculate a more accurate total days (which is no longer based on a fixed 12-month period but takes into account the contract's start date).
We also now calculate the number of months more accurately by taking, once again, the contract's start date into account.

Also adding a few test cases to test a bit more some special case we didn't yet test correctly.

task-6348903

Forward-Port-Of: odoo/enterprise#122580

#payroll#hong-kong#payment-in-lieu#salary-rules

[FIX] industry_fsm_sale: return empty mail.message recordset instead of False

PR #123010

Enterprise19.0industry_fsm_saleMedium

This fixes an error that could occur when changing quantities on confirmed field service sales orders while automated email/message rules are active. The update keeps internal message suppression working while returning the expected system object, preventing interruptions for users managing field service orders.

Original PR description

Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916

Forward-Port-Of: odoo/enterprise#119542

[FIX] project_enterprise: progress for gantt pill in task

PR #123039

Enterprise19.0project_enterprisetimesheet_gridMedium

Task progress shading in the Gantt view now correctly reflects hours worked against allocated hours. This fixes cases where a half-complete task appeared almost empty, helping users quickly understand task status at a glance.

Original PR description

Steps to reproduce: ------------------------------------------- 1. Install the Timesheet module with demo data 2. Go to any FSM task > set allocated hours to 20h 3. Fill the timesheet for the same…

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />

After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />

opw-6038983

Forward-Port-Of: odoo/enterprise#122899
Forward-Port-Of: odoo/enterprise#111270

When scanning a product barcode in the shopfloor, it would not simulate a click on the product if the corresponding BoM line was linked to an operation. Steps to reproduce: ------------------- * Create a BoM for product A with a BoM line for product B and link it to any operation. * Create a WO for product A and confirm it * Open the shopfloor with the WO and scan the barcode of product B > Observation: Nothing happens Why the fix: ------------ We simulate the onClick for the product even if the move is not marked manual_consumption. opw-6268665

When a Knowledge article embeds a kanban, calendar or map view and the user prints it or exports it to PDF, the view is missing and the printed page is blank. The Knowledge print stylesheet hides those embedded views in print mode. The rule was introduced with the print feature under the selector `.o_knowledge_embedded_view > .o_kanban_view`, but `.o_knowledge_embedded_view` is emitted nowhere in the templates or components, so the rule matched nothing and the embedded views were always printed. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rescoped the print rules and retargeted the selector to the real wrapper as `[data-embedded="view"] .o_kanban_view`. That selector matches, so the views are now hidden and the printed article is blank. Remove the rule from `knowledge_print.scss` so embedded views render again in print mode, restoring the behavior that held since the print feature was introduced. Steps to reproduce: 1. Open Knowledge and create a new article. 2. Click Build an Item Kanban, type a name and click Insert. 3. Add an item with Quick add so a card appears in the kanban. 4. Open the article options menu and click Download PDF. => The embedded kanban view is missing and the PDF is blank. Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6299703) opw-6299703

Lazada stores order statuses at the item level. When an item is canceled, we mirrored this by decreasing the ordered quantity on the sale order line. But if the item was already delivered, decreasing the quantity below the delivered amount is forbidden and raises a `UserError`, which aborts the whole order sync: ```python File ".../sale_stock/models/sale_order_line.py", line 420, in _update_line_quantity raise UserError(_('The ordered quantity of a sale order line cannot be decreased below the amount already delivered. [...]')) ``` In practice, item-level statuses only differ from the order status in exceptional cases. Stop syncing statuses at the item level and assume the entire order shares a single status, which avoids the quantity decrease and the resulting traceback. opw-6267730

Currently, the calculation of the payment in lieu of notice is assuming the employee worked a whole 12 months prior to it being paid. This is of course not always going the be case, and when it happens our calculation is often incorrect. We update the salary rule to calculate a more accurate total days (which is no longer based on a fixed 12-month period but takes into account the contract's start date). We also now calculate the number of months more accurately by taking, once again, the contract's start date into account. Also adding a few test cases to test a bit more some special case we didn't yet test correctly. task-6348903 Forward-Port-Of: odoo/enterprise#122580

Steps to reproduce: ---------------------------------------- 1. Install `industry_fsm_sale` and `base_automation` modules 2. Create a product with: * Type: Service * Create on order: Task * Project: Field Service 3. Create an automation rule with: * Model: Sales order * Trigger: Incoming message 4. Create and confirm a sale order with this product 5. Add another product to the SO via the catalog view: * Change the quantity to 2 or more Observation: ---------------------------------------- Traceback occurs: ``` File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post message_sudo = message.sudo().with_context(active_test=False) AttributeError: 'bool' object has no attribute 'sudo' ``` Root Cause: ---------------------------------------- * Catalog qty change calls `set_fsm_quantity()` method * Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83 * `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order * FSM's `message_post` override sees the context flag and returns `False` * When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False` Solution: ---------------------------------------- Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on opw-6276916 Forward-Port-Of: odoo/enterprise#119542

Steps to reproduce: ------------------------------------------- 1. Install the Timesheet module with demo data 2. Go to any FSM task > set allocated hours to 20h 3. Fill the timesheet for the same task for 10h 4. Navigate to FSM > My Tasks > Gantt view Observation: ------------------------------------------- Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50% Issue: ------------------------------------------- In the commit https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed. Solution: ------------------------------------------- Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module. Before --------------------------- <img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" /> After: -------------------------- <img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" /> opw-6038983 Forward-Port-Of: odoo/enterprise#122899 Forward-Port-Of: odoo/enterprise#111270