Daily updates from Odoo
Friday, January 30, 2026
9 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue in the French Profit and Loss report where account 649 was incorrectly categorized. The change aligns the report with French accounting standards (PCG 2025 & 2026) by moving the account to the appropriate 'Wages and Salaries' section. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves a bug where the 'Today' filter in Frontdesk was incorrectly displaying visitors due to timezone differences. The fix converts all date/time comparisons to UTC, ensuring accurate filtering regardless of the user's location. This ensures all visitor records are correctly displayed.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update addresses a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This correction ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization. It's a routine fix to maintain system stability.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update corrects a bug where the serial number on delivery orders was incorrectly updated when adding new items in the 'ready' state. The fix ensures that the original serial number is maintained, preventing discrepancies in inventory tracking and improving order accuracy. This resolves an issue impacting product traceability.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
A bug was causing the input field for campaign testing to disappear, requiring users to close and reopen the dialog to use it. This fix addresses a technical issue with how the system handles empty input fields, ensuring the field remains visible and functional. The scope was limited to marketing automation to prioritize this specific problem.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
This update corrects an issue where customer claims weren't being processed correctly due to a limitation in how VAT numbers were matched. Specifically, when a child invoice contact shares a VAT number with a parent partner, the system would incorrectly select a partner, preventing the correct account move from being found. This ensures claims are processed accurately.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105653 Forward-Port-Of: odoo/enterprise#103366
This update fixes an issue where users wouldn't receive a warning when entering invalid email addresses during shared sign request declines. Now, the system validates email formats and displays a clear warning message, preventing incorrect data entry and improving the overall user experience. This ensures data integrity and reduces potential errors.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create a shared sign request. - Try to decline the sign request. - Enter an email address in an invalid format. Issue: - No warning is shown to the user for an invalid email and An RPC_ERROR appears in the console. - This happens because the _check_signer_email_validity constraint fails when signer_email is not valid. Solution: - Validate the email format when the user submits the refusal request. - Show a warning message if the email format is invalid. task-5454929
This update resolves an issue where editing a bank statement line would incorrectly trigger recalculations for all related lines, including those that were already reconciled. The fix ensures that changes to individual bank statement lines only impact those lines, improving the stability and accuracy of bank reconciliation processes. This prevents unnecessary recalculations and potential data inconsistencies.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885 Forward-Port-Of: odoo/enterprise#105754
This update resolves a performance issue in the project timesheet report that was causing it to fail with large datasets. The team has optimized the query by using a more efficient join technique, resulting in a faster report load time (approximately 2 seconds).
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report…
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052 Forward-Port-Of: odoo/enterprise#105696 Forward-Port-Of: odoo/enterprise#102283