Friday, August 28, 2026
10 changes · saas-19.2
Enhancements to existing features
Improves accounting performance by adding a database index used when finding the latest journal entry sequence. This can reduce a previously very slow read operation from about a minute to under a second in affected cases, improving responsiveness for users working with accounting records.
Original PR description
This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`. The slow part is `.search(domain, order='date [desc|asc]', limit=1)` Because of the order by date,…
This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`. The slow part is `.search(domain, order='date [desc|asc]', limit=1)` Because of the order by date, postgresql scans the index on `date`, assuming a row will be quickly matched. If this assumption is wrong though, it'll scan a large part of the index or all of it, which is slow. This is the case with account move 17102258 on odoo.com at the time of writing this. - before - 1st query https://explain.dalibo.com/plan/6b8ff62b1572ah1a - 2nd query https://explain.dalibo.com/plan/41243cgccg5798gb - after - 1st query https://explain.dalibo.com/plan/4fd2c7ed28g7b138 - 2nd query https://explain.dalibo.com/plan/2heh6c6965c88h71 - ~~1st query https://explain.dalibo.com/plan/f874a31f4b07hdeb~~ - ~~2nd query https://explain.dalibo.com/plan/e8h09725gfh4c2e9~~ full `web_read` - before ~1min 10s - after ~650ms task-6481393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283159
Odoo now checks user permissions when related record changes are passed through context commands, matching the behavior of normal field updates. This prevents unauthorized changes from being silently skipped and makes access rules more consistent for project sharing and other workflows.
Original PR description
Some commands may perform a change on related records by using Commands. When passed through the context, unallowed actions are ignored instead of rising access errors. This check aligns the behaviour with normal writes of fields. A test in `project` module shows this behaviour. Backport of odoo/odoo#258845 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285266 Forward-Port-Of: odoo/odoo#284501
This update adds dedicated UAE overtime categories so payroll teams can calculate overtime pay more easily and consistently. It reduces manual setup and supports clearer salary rule calculations for weekday, night, and other overtime cases.
Original PR description
Add UAE overtime work entry types (OVTWD, OVTWDN, OVTOD) to simplify overtime salary rule calculations using `worked_days['<code>'].amount`. Task: 6469393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285053 Forward-Port-Of: odoo/odoo#282898
Companies sharing the same French SIREN in one database can now reuse a successful registration verification from another company. This reduces repeated KYC work for groups with many branches or entities and speeds up onboarding to French PDP services.
Original PR description
We have some clients that have several hundreds of companies/branches on the same db, with the same SIREN (incubateur or the like). They will need to do the kyc (that will be identical, as it's the same SIREN) for all the companies. It's especially cumbersome if it needs manual intervention So, if one company on that database, with the same SIREN, managed to register, then it means it has succeded the kyc. Meaning we can bypass the kyc for the other identifiers as well. task-6515315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285236
UAE payroll now includes the latest overtime salary rules aligned with a newer Odoo version. This helps calculate weekday, night, and rest-day overtime more directly and consistently for affected payslips.
Original PR description
Backport overtime salary rules (OVTWD, OVTWDN, OVTOD) from 19.4 to 19.0, updating the computation logic to directly use `worked_days['<CODE>'].amount`. Task:6469393 Forward-Port-Of: odoo/enterprise#129565 Forward-Port-Of: odoo/enterprise#127911
Deleting accounts is now more efficient because the system can verify related accounting and point-of-sale records more quickly. This reduces delays during cleanup or account maintenance without changing day-to-day workflows.
Original PR description
Without these indexes, the foreign key check when deleting an account can take a long time. Forward-Port-Of: odoo/odoo#284780
Deleting an account in the German reports module should be faster in larger databases. The change adds supporting indexes so the system can complete required checks more efficiently when an account is removed.
Original PR description
Without these indexes, the foreign key check when deleting an account can take a long time. Forward-Port-Of: odoo/enterprise#129403
The mail test suite now re-checks pending conditions more frequently instead of waiting up to 10 seconds in some cases. This reduces unnecessary test waiting time and helps developers get quicker, more reliable feedback without changing user-facing mail behavior.
Original PR description
Before this commit, a contains that does not match right away runs again only when its MutationObserver fires, and once more at the 10 seconds timeout. The problem is that the observer reports neither a text node updated in place nor an input value or checked property, so a check waiting for one of those sleeps 10 seconds and then passes: "Delete starred message decrements starred counter once" spends 10.2s of the 183s @mail suite waiting for a counter to go from "Starred3" to "Starred2". This commit turns that single timeout into a 500ms tick up to the same deadline, so that such a check costs 500ms. The tick uses the unmocked timer to stay out of the timer graph a test drives with runAllTimers, and only 32 of the suite's 4239 contains calls stay pending long enough to tick once. Forward-Port-Of: odoo/odoo#285129 Forward-Port-Of: odoo/odoo#284944
Closing Point of Sale sessions with many invoiced bank payments is now much faster and less likely to time out. The change groups payment reconciliation and invoice receivable line creation into batch operations, reducing a reported close time from over 9 minutes to under 1 minute.
Original PR description
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had…
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders). 3. Close the session. The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes. Cause ----- `_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments. `_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time. opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched. Fix --- Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment. Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards. Benchmark --------- Closing a session of 2081 invoiced orders on a copy of the customer database: - before: 558s - after: 54s opw-6458271 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284783 Forward-Port-Of: odoo/odoo#281495
Pay later receivable entries in Point of Sale settlement are now matched in one grouped operation instead of repeating the process for each customer. This keeps the accounting result unchanged while reducing processing time and system workload during settlement.
Original PR description
The pay later receivable lines are reconciled with one `reconcile()` call per partner, and each call filters the whole set of lines again. Reconcile them in a single `_reconcile_plan` call grouped by partner instead: the result is the same, but the recompute cascade of the ORM runs once instead of once per partner. opw-6458271 Related: https://github.com/odoo/odoo/pull/281495 Forward-Port-Of: odoo/enterprise#129406 Forward-Port-Of: odoo/enterprise#127415