Daily updates from Odoo
Friday, March 14, 2025
5 changes · 18.0
Enhancements to existing features
Stock transfers involving many serial numbers now validate much faster by avoiding repeated checks during inventory valuation. This reduces waiting time for warehouse and purchasing workflows, especially for large batches.
Original PR description
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change will reduce the time taken by each `_account_entry_move` and remove unnecessary calls. ### Benchmark (in 18): | # of moves | Before | After | |---------------------|----------|---------| | 8 (with 1000 each) | 13:57 | 3:46 | | 3 (with 1489 each) | 8min | 2:53 | | 1 (with 1489) | 2:47 | 36s | ### Reference: opw-4550348
This update improves how messaging interface components are loaded so they wait for their required background services to be ready. It reduces the chance of timing-related crashes when chatter or discussion features are loaded on demand.
Original PR description
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we…
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo/odoo#201504 Related to: odoo/enterprise#81462
This update prepares the Point of Sale system for a new Brazilian electronic invoicing localization by adding integration hooks that other modules can use. It does not change current user behavior, but it makes future country-specific POS capabilities easier to add and maintain.
Original PR description
[IMP] web: eslint the new l10n_br_edi_pos module task-3564171 ---- [IMP] point_of_sale: add some hooks for l10n_br_edi_pos This doesn't change behavior, only adds a way to modify the behavior from other modules. task-3564171
This update allows background color highlighting rules to be accepted on fields in list views. It removes a validation gap so existing visual styling options can be used reliably without being rejected.
Original PR description
The current validation only allows decoration-color attributes on fields on list views. The decoration-bg-color attributes are working as expected but are not in allowed in the rng yet. Adding the attributes to the rng.
This update changes how Studio registers key interface elements so they are only activated after the services they rely on are ready. This reduces the risk of timing-related crashes when parts of the interface, such as chatter-related features, load in the background.
Original PR description
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we…
When we create a public root, we do: - Create env - Wait for services to load - Create `MainComponentsContainer` In a usual scenario, all the services are started in the second step above, so when we create the MainComponentsContainer, all the services we need are already available. The problem with the lazy loading chatter bundle is that one of the services in the second step is responsible for loading that bundle. So while the lazy bundle is loading, new services and main components are being added to the registry. The steps could become like this: - Create env - Wait for services to start - Start loading chatter bundle - Lazy services (from chatter bundle) are not yet completely started - Main components of the lazy bundle are added to the registry - Lazy services are completely started It might cause a crash due to unavailable services when the main components are added depends on the timing of the deployment of the lazy services. This PR defines a new service for each main component that are added through the chatter bundle to ensure that main components are registered when their dependent services are deployed. backport of odoo/enterprise#81327 Related to : odoo/odoo#201771