Friday, August 28, 2026
9 changes · saas-19.3
Enhancements to existing features
Accounting records now use a better database lookup path when finding the latest sequence entry for a journal and date. This can dramatically reduce waiting time in affected accounting screens, with one measured case improving from about 70 seconds to under a 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 Forward-Port-Of: odoo/odoo#283159
Companies in the same database that share a SIREN can now reuse a successful identity verification from another company with that same SIREN. This reduces repeated manual KYC work for organizations managing many branches or entities 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
Job listings now only offer working schedules that match the job's company. This helps recruiters keep postings consistent and avoids selecting invalid schedules for a company.
Original PR description
In order to maintain proper job listings and make sure all working schedules are valid, working schedule domain is now depeding on the job listing company. Task: 6408914 Forward-Port-Of: odoo/enterprise#129199 Forward-Port-Of: odoo/enterprise#128241
Recruitment job listings now limit available working schedules based on the company tied to the job. This helps keep job postings consistent and prevents invalid schedule choices across companies.
Original PR description
In order to maintain proper job listings and make sure all working schedules are valid, working schedule domain is now depeding on the job listing company. Task: 6408914 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284487 Forward-Port-Of: odoo/odoo#282993
Neutralized test databases will no longer keep a placeholder Belgian POS fiscal identifier. This allows businesses to detach the blackbox from a POS configuration and use 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.
Self-billing bills now keep separate numbering per partner, improving traceability and reducing confusion in accounting records. The change also allows dedicated self-billing sales journals so imported self-billing invoices no longer affect regular sales journal sequences.
Original PR description
This PR handles 2 cases : ===== PART 1 ===== Self-billing bill sequences should be unique per partner, as implemented in v19+. This PR backports that behavior to 17.0. ===== PART 2 ===== Previously, the `is_self_billing` option on `account.journal` was available only for purchase journals. This caused an issue when importing a self-billing invoice into a regular sales journal with quick edit mode (accounting firm) enabled. In such cases, the newly created invoices would use the self-billing sequence pattern, leading to traceability issues. This PR allows the creation of self-billing sales journals to prevent this issue. task-6103142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282062 Forward-Port-Of: odoo/odoo#259935
Mail test checks now retry pending content matches every 500ms instead of waiting up to 10 seconds for certain UI changes. This reduces wasted test time and helps the team get quicker, more reliable feedback without changing customer-facing 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
This update adds database indexes that make it faster to verify whether an account can be deleted. It helps reduce delays in accounting and point of sale workflows when removing unused accounts.
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
This update improves the German reports module by making account deletion checks faster. It reduces delays when removing accounts, helping users complete maintenance tasks more smoothly without changing visible workflows.
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