Thursday, August 20, 2026
9 changes · saas-19.3
Enhancements to existing features
Portal task searches now avoid a slow lookup pattern that forced the system to scan all tasks. Users should see much quicker results when searching task lists, especially in large databases.
Original PR description
The portal task list searched titles with
['|', ('name', 'ilike', search), ('id', 'ilike', search)]. Applying ilike to the integer id casts it to text, which no index can serve, and OR-ing that branch with the title prevents the trigram index on name from being used at all, so every search fell back to a full scan of project_task. The id branch is now added only when the term is numeric, as an equality on the primary key, keeping the title lookup on its trigram index.
Benchmark on 200k tasks, PostgreSQL EXPLAIN ANALYZE, selective term matching 5 rows, median of 3 runs:
before Parallel Seq Scan on project_task ~150 ms
after Bitmap Index Scan (name gin_trgm_ops) ~0.5 ms
opw-5478903
Forward-Port-Of: odoo/odoo#278548Accounting validation errors now include more useful details, such as the affected account code or journal entry reference. This makes FEC imports and related accounting troubleshooting faster because users can identify the problematic record more easily.
Original PR description
Some generic validation errors raised by core account models lack enough context to identify which record caused the issue, making FEC imports harder to troubleshoot. This commit improves the two…
Some generic validation errors raised by core account models lack enough context to identify which record caused the issue, making FEC imports harder to troubleshoot. This commit improves the two error cases identified for this use case: - `account.account._check_account_code` now includes the invalid account code in the error message. - `account.move.write` now includes the move name/reference and displays human-readable field labels instead of technical field names when attempting to modify read-only fields on posted entries. Although motivated by FEC import, these are generic core validations, so the improvements are implemented at the source to benefit all callers rather than only the FEC import flow. Enrichment is scoped to the two cases above, other constraints/errors across these models are intentionally left unchanged for now, since editing core error messages more broadly should be done deliberately and on a case-by-case basis, not as a blanket rewrite task-5346068 Forward-Port-Of: odoo/odoo#282840 Forward-Port-Of: odoo/odoo#281746
Resolved issues and error corrections
When users try to archive an accounting journal that still has draft entries, the error message now points them to the correct place where those entries can be found and resolved. The journal form button was also renamed so it accurately reflects that it opens journal items, reducing confusion and helping users complete the archive process.
Original PR description
> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent…
> Replaces https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side: the branch was pushed from a shallow clone and its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here. ### Steps to reproduce 1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line. 2. Go to `Accounting > Configuration > Journals`, open that journal and archive it. 3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*. 4. Follow those steps: click the `Journal Entries` smart button on the journal form. ### Current behaviour The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist. The instructions cannot be followed: - The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match. - That action defaults to `search_default_posted: 1`, so no draft record is listed. - Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter. - The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`. - The filter is labelled **"Unposted"**, not "Draft". The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted". ### Expected behaviour The error should point to a view where the records blocking the archiving are actually listed and actionable. ### This PR Two changes, the validation itself is unchanged: - The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted". - The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR. Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master. Forward-Port-Of: odoo/odoo#282956
Italian electronic invoicing now handles simplified invoices more reliably, including the correct virtual stamp duty information. It also prevents simplified invoices from being used for public administration or non-domestic customers, reducing compliance errors.
Original PR description
- Added the BolloVirtuale in the Simplified invoice template - Now it's possible to force the Simplified format on exported invoice when the `l10n_it_document_type` is set to a simplified one - Factored the Italian partner recognition (_l10n_it_edi_is_italian) - Added a check on the invoice, no simplified format for non-domestic / PA partners Task [link](https://www.odoo.com/odoo/project.task/6226436) task-6226436 Forward-Port-Of: odoo/odoo#283154 Forward-Port-Of: odoo/odoo#274493
Fixed an issue where creating a new analytic distribution model while updating multiple journal items would close the dialog before users could complete it. This ensures accounting users can finish and save new distribution models during mass edits without interruption.
Original PR description
When mass-editing the Analytic Distribution field on several records at once, and creating a new distribution at once, will close the creation dialog before the user could fill it in. Steps to reproduce: - Enable Analytic Accounting - Open Accounting > Journal Items - Enable the Analytic Distribution column - Select 2 journal items and click on the Analytic Distribution - Click on 'Update', fill a distribution, then click "New Model" - Confirm the multi-edit update Issue: The create Analytic Distribution model dialog closes on its own instead of staying open, so the model can never be saved. Analysis: After https://github.com/odoo/odoo/commit/12a61fa5ab7c56a42020c50c683df8ed52f1fb01, in multi-edit, save() ends reloading the list, unmounting the AnalyticDistribution widget, that closes the model dialog it just opened. opw-6405219 Forward-Port-Of: odoo/odoo#281141
French customers with a valid SIREN or SIRET but no VAT number are now correctly treated as business customers for e-Invoicing. This prevents eligible invoices from losing the French e-Invoicing sending option simply because the VAT number is missing.
Original PR description
**Steps to reproduce:** - Install module `l10n_fr_pdp` and configure French e-Invoicing. - Create a customer has a valid SIREN/SIRET (company_registry) but no VAT number. - Create an invoice for the customer and confirm the invoice. - Check the available sending methods. **Observed Behavior:** The French E-Invoicing option is disabled because the customer is identified as a B2C partner when no VAT number is set. **Cause**: The B2C detection relies on the partner's VAT number instead of its SIREN/SIRET. As a result, French companies without a VAT number but with a valid SIREN are classified as B2C. **Fix**: Determine whether a partner is B2C based on the presence of a valid SIREN/SIRET (derived from `company_registry`) instead of the VAT number. This correctly identifies French business partners that are eligible for French e-Invoicing even when they do not have a VAT number configured. opw-6357756 Forward-Port-Of: odoo/odoo#278060
Swiss payroll now counts full-day flexible absences using the dates employees requested, avoiding timezone-related extra days. This prevents one-day accident leave from being treated as two days, helping keep regular wage and accident salary calculations accurate.
Original PR description
Issue: Swiss payslips count one extra absence day for employees without a working schedule. A one day accident leave can therefore be prorated as two days, reducing the regular wage and overstating…
Issue: Swiss payslips count one extra absence day for employees without a working schedule. A one day accident leave can therefore be prorated as two days, reducing the regular wage and overstating the accident salary. Steps to reproduce: * Install Swiss Payroll. * Configure a monthly employee without a working schedule. * Assign one day of accident time off. * Generate the payslip for that month. Cause: The Swiss wage computation derives absence boundaries from the date portion of the leave's UTC datetimes: https://github.com/odoo/enterprise/blob/16c29e1bab34b5bcb2b001477d928ec5eb294a97/l10n_ch_hr_payroll/models/hr_payslip.py#L313-L330 A fully flexible employee's full day leave starts at local midnight. In timezones ahead of UTC, that start is stored on the previous UTC date, so the inclusive calendar day computation adds an extra day. Solution: We need to use the requested time off dates for both payslip range filtering and absence proration. These fields preserve the calendar days selected by the user independently of timezone conversion, while leaving the UTC datetimes and half-day handling unchanged. opw-6435086 Forward-Port-Of: odoo/enterprise#127849 Forward-Port-Of: odoo/enterprise#127513
SEPA direct debit payment files now include a required scheme name field for the initiating party. This helps ensure files are accepted by banks that require it, such as Nordea in Sweden, reducing payment processing failures.
Original PR description
We are missing a SchmeNm node in the InitgPty node. This is mandatory for Nordea in Sweden at least. Such as: ```xml <SchmeNm> <Cd>CUST</Cd> </SchmeNm> ``` task-6385960 Forward-Port-Of: odoo/enterprise#124693
Out-of-office return dates now appear reliably for employees in Discuss, even when viewers do not have access to the employee's company. This prevents missing availability information in sidebars, member lists, and chat banners, helping teams see colleague availability more consistently.
Original PR description
*=hr_holidays,im_livechat,mail,test_discuss_full Out-of-office return dates were loaded through the partner's main user's employee_ids. That relation is company-filtered, so users without access to the employee's company did not receive leave_date_to in Discuss until opening the avatar card refreshed the data through another path. This commit fixes this behavior by loading leave_date_to from all employees linked to the partner's main user using sudo and exposing them through the all_employee_ids store relation. This makes the out-of-office indication consistently available in the sidebar, member list, and chat banner. task-6095661 Forward-Port-Of: odoo/odoo#283047 Forward-Port-Of: odoo/odoo#263149