Daily updates from Odoo
Monday, July 6, 2026
13 changes · saas-18.2
Resolved issues and error corrections
Task progress bars in the Gantt view now show the correct amount of completed work. This fixes a display issue where partially completed tasks appeared almost empty, helping users better understand task progress 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…
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#111270
This fix prevents an error when users update product quantities on confirmed field service sales orders while automated message rules are active. The system now safely suppresses unnecessary chatter messages without breaking automation, keeping sales order updates reliable.
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:…
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#119542The Peppol settings now apply the right rule for when a purchase journal is required, especially when French PDP features are installed. This prevents non-French companies using Documents for Peppol imports from being blocked by an unnecessary journal requirement, and ensures imports go only to the selected destination.
Original PR description
Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120717
This fixes an issue where multiple upsell orders linked to the same subscription product could lose their connection to the original subscription line. The change prevents duplicate product lines from being created on the parent subscription when upsells are confirmed, improving subscription billing accuracy.
This change updates the subscription sales process so scheduled invoicing can complete more reliably. It helps reduce missed or delayed invoices, supporting smoother recurring revenue operations.
This update fixes automated test checks for Web Studio's report editor. It helps keep internal quality controls reliable so future changes can be validated with less risk of hidden regressions.
Original PR description
https://github.com/odoo/odoo/pull/210144
This fix ensures DHL commercial invoices receive a valid invoice number when deliveries are validated from a company other than the main company. It prevents DHL shipment validation failures for international deliveries that require dutiable material documentation.
Original PR description
Issue ----- When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end.…
Issue ----- When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end. `content/exportDeclaration/invoice/number: expected type: String, found: Boolean` Steps to reproduce ----- - Create a Belgian company - Setup DHL - DHL Product D - Express Worldwide - Dutiable Material enabled - Create an amrican customer - Deliver a product to the american customer > Validation Error Cause ----- The field is populated in https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/delivery_dhl_rest/models/dhl_request.py#L204 The problem is that `next_by_code` uses the company found in the env, whereas the sequence's company is the main one, so it is not found when doing https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/odoo/addons/base/models/ir_sequence.py#L287 ----- Ticket: opw-6171886 Forward-Port-Of: odoo/enterprise#118379
Chilean export invoice PDFs now keep the customs information table columns aligned even when origin or destination ports are not provided. This prevents package quantities from appearing under the wrong headings, improving document accuracy for exports.
Original PR description
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by…
### Issue: On Chilean export invoices, the customs information table may display data in the wrong columns When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document ### Cause: `l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields `t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set ### Steps to reproduce: - Install `l10n_cl_edi_exports` and switch to CL Company - Create an Invoice (any customer, any line) - In the gear menu, select Print > Invoice PDF copy (Chile) Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set opw-6304670 Forward-Port-Of: odoo/enterprise#121923
Project-linked document folders are no longer deleted by the automatic trash cleanup when they are archived. This prevents cleanup jobs from failing and keeps project document access reliable, including for archived projects.
Original PR description
## Problem When a folder linked to a project gets archived, the documents trash autovacuum unlinks it along with regular trash. That triggers the constrains . This happens whether the project is still active or also archived. ## Fix Exclude in the domain the documents attached to projects so the document is not deleted if linked to a project Forward-Port-Of: odoo/enterprise#122135
Fixes an error that could stop users from generating the Swiss payroll monthly summary spreadsheet. The report now handles its data correctly, allowing payroll teams to export the file without interruption.
Original PR description
RPC_ERROR Odoo Server Error ``` Occured on syctest18.sodexis.com on model l10n.ch.monthly.summary on 2025-07-07 08:00:08 GMT Traceback (most recent call last): File…
RPC_ERROR
Odoo Server Error
```
Occured on syctest18.sodexis.com on model l10n.ch.monthly.summary on 2025-07-07 08:00:08 GMT
Traceback (most recent call last):
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/http.py", line 2175, in _transactioning
return service_model.retrying(func, env=self.env)
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/service/model.py", line 161, in retrying
result = func()
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/http.py", line 2142, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/http.py", line 2393, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/addons/base/models/ir_http.py", line 340, in _dispatch
result = endpoint(**request.params)
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/http.py", line 759, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/syctest18-odoo/src/18.0/addons/web/controllers/dataset.py", line 33, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/syctest18-odoo/src/18.0/odoo/service/model.py", line 83, in call_kw
result = method(recs, *args, **kwargs)
File "/opt/odoo/syctest18-odoo/src/18.0-Ent/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_monthly_summary.py", line 134, in action_generate_xls
line_values = self._get_line_values()
File "/opt/odoo/syctest18-odoo/src/18.0-Ent/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_monthly_summary.py", line 106, in _get_line_values
lines = [
File "/opt/odoo/syctest18-odoo/src/18.0-Ent/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_monthly_summary.py", line 108, in <listcomp>
for code, name, total in sorted(data.items(), key=lambda x: x[0][0]) # Sort by code
ValueError: not enough values to unpack (expected 3, got 2)
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://syctest18.sodexis.com/web/assets/ea37c94/web.assets_web.min.js:2978:163)
at XMLHttpRequest.<anonymous> (https://syctest18.sodexis.com/web/assets/ea37c94/web.assets_web.min.js:2983:13)
```This fix changes how accounting-related demo data is prepared so it can work more reliably across multiple companies. It also gives better control over which accounts and journals receive demo records, avoiding unwanted setup requirements before the system is ready.
Original PR description
It gives more flexibility in various aspects: * we can install the demo on multiple companies, like already done for invoices etc * we have a finer choice on which accounts and journals we want to select (i.e. no asset on the Tax Adjustment journal) * we don't force installing a chart of accounts for the main company before the registry is loaded
The EU IoT scale certification module is no longer available for installation in this version. This avoids customers enabling a certification feature that will only be supported in major releases.
Original PR description
This PR makes the module non installable as the scale certification will only be available in major versions Upgrade PR: https://github.com/odoo/upgrade/pull/8537
Fixed an issue where the option to request signatures could disappear on some forms depending on how users opened them. The change ensures the option is shown whenever the form has the activity and message area needed to track signature requests.
Original PR description
### Issue: In #61250, the `SignRequestCogMenuItem` allowing for signature requests was removed from forms that did not have a chatter to track the actual requests. In 18.1, the method used to do this no longer works, so the button is now hidden on certain Views depending on how you access them. ### Solution: The conditions to meet haven't changed, so we can instead use the `chatter` itself. On form views with a chatter, the `Chatter` component will set the `fetchThreadData` to false, which we can check for. opw-4817423