Saturday, August 22, 2026
10 changes · master
Enhancements to existing features
This update brings the spreadsheet component to a newer version, improving visual consistency and fixing several usability issues. Users should see cleaner icons and styling, more reliable scorecard charts, and better behavior when viewing spreadsheets in standalone or dashboard contexts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a73559ee4f [REL] 19.5.0-alpha.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a73559ee4f [REL] 19.5.0-alpha.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bb965c63da [FIX] icons: align data filter icon with material icon [Task: 6276321](https://www.odoo.com/odoo/2328/tasks/6276321) https://github.com/odoo/o-spreadsheet/commit/8900dbec98 [IMP] icons: replace script as cjs instead of python [Task: 6276321](https://www.odoo.com/odoo/2328/tasks/6276321) https://github.com/odoo/o-spreadsheet/commit/a5ef0a0405 [FIX] css: fix issues with the new material design [Task: 6475791](https://www.odoo.com/odoo/2328/tasks/6475791) https://github.com/odoo/o-spreadsheet/commit/08b1a1d180 [FIX] standalone_viewport: stop following selection [Task: 6481678](https://www.odoo.com/odoo/2328/tasks/6481678) https://github.com/odoo/o-spreadsheet/commit/f66629eea7 [IMP] charts: scorecard now uses formula instead of cell reference [Task: 6343843](https://www.odoo.com/odoo/2328/tasks/6343843) https://github.com/odoo/o-spreadsheet/commit/b289465e09 [IMP] menu_registry: ensure children unicity [Task: 5224033](https://www.odoo.com/odoo/2328/tasks/5224033) https://github.com/odoo/o-spreadsheet/commit/9358c3ddc8 [FIX] inputs: explicitly define border-style [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This change increases a temporary lookup cache used while importing data, reducing repeated database queries for large files with many reused references. It keeps the imported data unchanged while lowering database round trips during certain module installations, with only a small temporary memory increase.
Original PR description
`BaseModel.load()` resolves every `field:id` column through `ir.model.data` one row at a time, behind a fixed 1024-entry LRU. A data file that references more distinct external ids than the cache…
`BaseModel.load()` resolves every `field:id` column through `ir.model.data` one row at a time, behind a fixed 1024-entry LRU. A data file that references more distinct external ids than the cache holds, and reuses them across rows, overflows it immediately, so almost every row misses and costs a query. `l10n_us/data/res.city.csv` is the only file in the codebase that does both: 31,236 rows over 3,172 counties. Installing the module costs 14,610 queries. Raising the cache to 10000 brings that to 3,859 with no change to the data loaded. Module load time is unchanged, the gain is in database round trips. An entry is an external id mapped to a (model, id) tuple, and the LRU keeps a second dict to track ordering, so about 190 bytes each. The cache is built per `load()` call and dropped when it returns, and it fills to the number of distinct external ids in the file rather than to its cap: | entries | case | bytes | MB | |---|---|---|---| | 1,024 | today's cap | 207,248 | 0.2 | | 3,223 | res.city.csv working set | 640,240 | 0.6 | | 10,000 | cap reached | 1,878,288 | 1.9 | No data file in either repo reaches the cap. task-none
Manufacturing work orders now behave more consistently for continuous production, reducing accidental quantity changes that could disrupt component consumption. The update also improves safeguards when multiple users work on the same order and streamlines work order behavior after completion.
Original PR description
In this commit, we continue cleaning and aligning continuous production BoM with normal BoM alongside some UX changes and improvements. In case of a continuous production BoM: - Marking a WO as done, doesn't update qty producing - Interacting with the WO card in shopfloor also will not update qty producing, because it used to mess up component's consumption. Move demand should only be updated when we update MO's quantity producing. In General: - No production state tracking in the chatter for WO Form - Allow splitting when WO is done - Ensuring that if there are 2 users working on the same time and one of them marks the WO is done, the other won't be able to update the `qty_produced` on accident and will be shown an error to avoid inconsistencies. Task: 6384174 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275973
Invoice rounding can now be managed directly from the main invoice screen and edited more easily. Rounding rules can also be applied automatically only when configured conditions are met, helping sales invoices use the right rounding without changing the original sales order or recalculating incoming supplier values.
Original PR description
This commit improves rounding methods usage on sales moves The improvements are the following: 1) Allow users to manage and adjust rounding directly from the main invoice form view (instead of the "Other Info" tab) and enable inline editing on the rounding list view. 2) Restrict automatic rounding calculations strictly to active sales/invoicing flows. Passive incoming flows must respect received values without recomputation. 3) Introduce configurable conditions directly on rounding methods so they apply automatically only when specific criteria are met (e.g., currency-specific rules). 4) Ensure rounding automatically applies to invoices generated from Sales Orders (when conditions are met) without requiring structural changes to the Sales App or forcing the original SO to be rounded. task-6479888
Website page-building snippets were refined with better layouts, categorization, and visual polish, including a new intro spotlight option. These updates make it easier for users to create more attractive website pages with less manual adjustment.
Original PR description
- Requires https://github.com/odoo/design-themes/pull/1321 task-6374308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now transfer checks in bulk between companies or sibling branches they can access. The check’s company is kept aligned with its latest movement, improving accuracy for multi-company operations.
Original PR description
[IMP] l10n_latam_check: allow transfer between accessible branches Allow to mass transfer checks between active companies, and in particular between sibling branches. By doing this, we exposed even more the fact that a check can be received in a journal belonging to a company, then be moved to another company's journal. Previously, when that hapenned (it was already possible to transfer from children to parent), the company_id of the check stayed where the creation payment hapenned. Which was never correct but not too exposed. We fix it by making it a computed stored field based on the value of the last operation related to the check. We also simplify the domain of the check list view to just rely on the initial payment method used. task-5247520
Accounting validation errors now include more helpful details, such as the affected account code or journal entry reference. This makes FEC import issues and related accounting errors easier to identify and resolve without extra investigation.
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#283279 Forward-Port-Of: odoo/odoo#281746
Portal task searches now avoid a slow lookup pattern that caused large task lists to be scanned unnecessarily. Users should see much faster search results when looking up tasks by title, especially in databases with many tasks.
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#278548Odoo's Amazon sales connector has been updated to use Amazon's newer Orders API ahead of the old version being retired in 2027. This keeps Amazon order synchronization compatible and should improve performance by retrieving order and item details together instead of through repeated extra calls.
Original PR description
Amazon has announced the deprecation of the Orders v0 API, with a removal date of March 27, 2027. In this commit, we migrate to the new v2026-01-01 API. This new version restructures how order data is queried and delivered, shifting from a multi-request architecture to a nested consolidated payload. This optimizes our sync performance by eliminating the N+1 query problem when fetching order items. Key changes: - Operation Consolidation: `getOrders` is replaced by `searchOrders`. Because Amazon now embeds orderItems directly inside each order object natively, we remove our secondary item-fetching loops. - Financial aggregation: Item prices, taxes, shipping, and discounts are no longer flat fields on the item but are centralized into a `proceeds` object. - Replacing of deprecated flags. - Reorganization of order-related fields. task-5972714 Forward-Port-Of: odoo/enterprise#128763 Forward-Port-Of: odoo/enterprise#114591
Shopfloor handling for continuous production has been tightened to avoid creating backorders in this flow for now. Users must enter a produced quantity before closing a manufacturing order, helping prevent unclear or incorrect production records.
Original PR description
Forward-Port-Of: odoo/enterprise#124696