Friday, August 28, 2026
8 changes · 19.0
Enhancements to existing features
Companies sharing the same French SIREN in one database can now reuse a successful identity check from another company. This reduces repeated manual KYC work for groups with many branches or entities registered under the same identifier.
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
Odoo now checks user permissions more consistently when related records are changed through background context commands. Unauthorized changes are ignored in the same way as standard field updates, reducing unexpected access errors and improving data protection consistency.
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#285132 Forward-Port-Of: odoo/odoo#284501
Neutralized test databases will now clear the Belgian POS fiscal identifier instead of keeping a placeholder value. This lets businesses remove the blackbox from POS configurations and continue using the POS normally in test environments.
Original PR description
When a database is neutralized, the fiscal data module keeps a dummy l10n_be_pos_id on every pos.config. As long as this value is set, the blackbox cannot be detached from the configuration, which blocks any use of the POS on a neutralized (test) database. Empty the field instead of setting a dummy identifier, so the blackbox can simply be removed from the config and the POS used normally.
This change improves the speed of retrieving recent accounting entries by adding a more suitable database lookup path. It helps reduce long wait times in accounting screens, with the reported operation improving from about 70 seconds to under 1 second.
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
Large point of sale sessions with many invoiced card or bank payments now close much faster. The process batches payment reconciliation and invoice line creation, reducing long waits and avoiding timeout failures for high-volume stores.
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 reconciled in one grouped operation instead of many repeated operations. This keeps the accounting result unchanged while reducing processing overhead, especially for sessions with many customers using pay later.
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
This update simplifies how guided tour pointers and tooltips are displayed in Odoo. It makes the tour guidance easier to maintain and more reliable without changing the business workflow for users.
Original PR description
The tourPointer component is only used in tours, so there's no need to make it a generic component that can be reused elsewhere. We use the usePopover hook to place the tooltip and its contents in the window. We use the usePosition hook to position the anchor in the window. We remove the responsibility from TourPointer to calculate the positions of the baball and the tooltip. We remove the tour_pointer_state file and export a reactive pointerState that allows us to manipulate easier the tourPointer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mail test checks that are waiting for screen content now re-check more frequently instead of waiting up to 10 seconds. This reduces unnecessary delays in automated testing, helping developers validate mail changes faster without affecting end users.
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#284944