Daily updates from Odoo
Thursday, November 13, 2025
8 changes · master
Enhancements to existing features
Belgian point-of-sale blackbox messages are now queued so the register can continue more quickly when an immediate response is not required. This improves reliability and reduces delays for workflows such as pro forma sales while preserving communication with the fiscal device.
Original PR description
In this commit, we introduce a queuing mechanism for blackbox messages to make all interactions with the blackbox faster and more reliable. This is particularly useful for messages that do not require the response from the blackbox to continue the workflow such as pro forma sales messages. Forward-Port-Of: odoo/enterprise#98040 Forward-Port-Of: odoo/enterprise#90747
Tax return generation is now more efficient by grouping repeated checks and updates, reducing delays when saving fiscal year settings or refreshing returns. The change also prevents manually created draft returns from being removed incorrectly, helping preserve user-entered accounting work.
Original PR description
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in…
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in action_save_onboarding_fiscal_year since we want to call it only when a value is changed and that's already handled in the write on the company. - batched _is_available_for on reports - make only one write on the company (and one call to _generate_or_refresh_all_returns) when writing or create the fiscal year wizard. - dont delete return created manually with a date before the date of the account_opening_date and not yet posted. Detected from runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231463 A small workaround is needed on the company when writing the changes from the fiscal year wizard. This is because related fields are writen one by one, which then trigger multiple times _generate_or_refresh_all_returns. To prevent this, we are batching all the write on the company from the fiscal year wizard in one write. The opening_date need to be handled separatly since it's not a related field but still need to be writen on the company, if removed from the vals during the create it's then not possible to save the wizard anymore. Also fixed a bug where the returns manually created before the account_opening_date would be deleted if they were not posted before the next call to _try_create_returns_for_fiscal_year. **Detailed Explanation** We can see the tour being broken when trying to save on the wizard: <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" /> So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year` <img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" /> The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules. Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph: <img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" /> The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. <img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" /> We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s BUT, we can still do better. We can see that all we did previously was only do to one thing less. The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`. <img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" /> After the final change, we are down to 0.9s ! One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases. Forward-Port-Of: odoo/enterprise#95760
A new setting lets users choose to disable barcode lookup instead of being forced to keep it active when an API key is automatically provided. This gives SaaS customers clearer control over the feature and can guide them through uninstalling the module when they no longer want to use it.
Original PR description
### Issue: Currently, the `product_barcodelookup` feature is disabled only when no API key is configured: https://github.com/odoo/enterprise/blob/86937d9c974125d60f6e2e9dc6bf0b048e20e489/product_barcodelookup/models/product_template.py#L199-L203 https://github.com/odoo/enterprise/blob/86937d9c974125d60f6e2e9dc6bf0b048e20e489/product_barcodelookup/tools/barcode_lookup_service.py#L7-L11 FHowever, for SaaS users, the API key is hardcoded, which makes it impossible to disable the feature without uninstalling the module. ### Improvement: The purpose of this commit is to add a boolean setting that allows users to explicitly disable the barcode lookup feature by proposing to uninstall the module for them. Community: https://github.com/odoo/odoo/pull/232794 opw-5096468
The report editor now automatically places the cursor in the first editable area when a report opens. This makes it clearer where users can begin editing, especially for new or blank reports, and shows the relevant placeholder guidance immediately.
Original PR description
Before this commit it was a bit hard to see where to click to start editing a report especially a blank or new one. After this commit, we focus the first hintable node that we can discover. This will: 1. Put the selection and cursor in that element 2. Trigger the hint plugin that will display the relevant placeholder task-4936527
The spreadsheet interface now supports dark mode using shared styling variables, giving users a more comfortable viewing option in low-light environments. This also simplifies future visual maintenance by avoiding separate dark-mode stylesheets.
Original PR description
This commits implements dark mode for the user interface in o-spreadsheet. We can drop the drak mode-specific stylesheets and use CSS variables using `light-dark()` instead. Task: 5082659
Record creation controls in kanban and list views now use proper buttons, so they are automatically disabled while another action such as saving is in progress. This prevents users from accidentally triggering conflicting actions on slow connections, reducing crashes and improving reliability across affected workflows.
Original PR description
Before this commit, the `Add a record` in x2many kanban was a `<div>`, and the `Add a line` (and other "creates") in lists were `<a>`. Using buttons is semantically more correct. Morevoer, buttons are disabled when an action is ongoing in the webclient. For instance, when the form view is being saved, buttons are disabled. This allows to avoid concurrent and unwanted behaviors. Before this commit, such a behavior could happen with x2manys: in a form view with some changes (and on a slow network), click on the save icon, and directly click to add a record in the x2many. That "add" request was done on the current version of the static list, but that static list was replaced by a new one when the record is reloaded (post save), so a crash occured. By using `<button>`, those actions are automatically disabled when saving, thus removing the race condition.
User-facing wording has been updated from “Shipping Methods” or sales-level “Carrier” labels to “Delivery Methods” across supported delivery and marketplace integrations. This makes sales and delivery settings more consistent and easier to understand, while keeping carrier wording where it still applies to warehouse or provider-specific operations.
Original PR description
delivery_* = bpost, dhl, easypost, envia, fedex, sendcloud, shiprocket, starshipit, ups, usps, ups_rest, delivery_easypost, delivery_shiprocket, l10n_br_edi_website_sale, sale_amazon, sale_shopee…
delivery_* = bpost, dhl, easypost, envia, fedex, sendcloud, shiprocket,
starshipit, ups, usps, ups_rest, delivery_easypost, delivery_shiprocket,
l10n_br_edi_website_sale, sale_amazon, sale_shopee
With this PR:
---
1. Renamed 'Shipping Methods' to 'Delivery Methods'
* Renamed all user-facing labels of "Shipping Method(s)" to "Delivery Method(s)"
for consistent terminology across apps and improved user clarity, without
altering terminology used by specific delivery providers or third-party
integrations.
2. Renamed 'Delivery Carrier'/ 'Carrier' to 'Delivery Methods'
* A `Carrier` label is used at the stock level, while `Delivery Method` is used at
the sales level.
* A Delivery Method represents the complete carrier process along with the
required parameters defined at the sales level, whereas a Delivery Carrier
(or Carrier) is used at the transfer/picking level, where the focus is on
which carrier actually ships the goods rather than the full delivery
configuration.
* Therefore, all relevant occurrences of Delivery Carrier have been updated to
Delivery Method.
* The remaining occurrences of Carrier/Delivery Carrier refer either to
stock-level usage, delivery provider's internal labels, or
localization-specific terminology.
Impact:
-------
- This avoids confusion between "Shipping Method" and "Delivery Method", as
"Delivery Method" better reflects how an order is handed over to the customer,
making the terminology clearer and more contextual.
- Clarifies when "Delivery Method" vs. "Carrier" should be used by keeping "Carrier"
terminology where it correctly reflects stock-level operations, while ensuring sales-level
terminology remains consistent.
task-4720174Currency rates will now use only values from before the requested date, reflecting that rates apply to the following day and should remain stable during the day. This improves consistency in accounting, reporting, payments, and electronic invoicing where exchange rates affect financial amounts.
Original PR description
Currency rates are valid for the next day and should not change during the day. Use only rates strictly earlier than the requested date task-5173684