Friday, March 14, 2025
10 changes
5 changes
Enhancements to existing features
This update aligns internal naming for how project task filters are optimized with a related platform change. It helps keep the Enterprise codebase consistent and maintainable without changing day-to-day user workflows.
Original PR description
Companion of https://github.com/odoo/odoo/pull/201587.
Odoo is changing its company information provider from Clearbit to Dun & Bradstreet to improve the reliability of partner and invoice data enrichment. Company logos will still come from Clearbit for now, while the main business data is fetched through the updated provider routes.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/196373 Enterprise PR: https://github.com/odoo/enterprise/pull/78489 Upgrade PR: https://github.com/odoo/upgrade/pull/7192 IAP PR: https://github.com/odoo/iap-apps/pull/984
Rental product checkout now avoids repeating stock checks already handled by the standard ecommerce flow. This simplifies the availability logic and should make cart validation faster while keeping stock controls consistent.
Ecuadorian companies can now record required dividend details when creating purchase withholdings for shareholder profit payments. This helps ensure electronic withholding documents and ATS reports include the payment date, related company income tax, and fiscal year required for compliance.
Original PR description
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. Fields required in…
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. Fields required in withholding wizard, XML and ATS report - **Dividend payment date:** it can be different to withhold date. It must be showed in ATS **`<fechaPagoDiv>`** and XML **`<fechaPagoDiv>`** - **Dividend income tax:** value of the Income Tax paid by the company that corresponds to the reported dividend. The computation of this value can be quite varied because of several parameters (exemptions, non-deductible expenses, deferred taxes, shareholder participation,annual withholding table with fixed withholding for the basic fraction, etc...). It must be showed in ATS **`<imRentaSoc>`** and XML **`<imRentaSoc>`** - **Dividend fiscal year:** The fiscal year in which earnings on the reported dividend are generated. The company could pay previous periods. It must be showed in ATS **`<anioUtDiv>`** and XML **`<ejerFisUtDiv>`** - **Show fields dividend:** Computed field to show the dividends fields. latam-865
Duplicating Helpdesk tickets and Planning shifts now avoids assigning archived users or resources. This prevents work from being accidentally assigned to people or resources that are no longer active, improving data accuracy and day-to-day operations.
Original PR description
_*=planning ### Before this commit: In Helpdesk, archived user are copied into new tickets when a ticket is duplicated. In Planning, archived resources are added to new shift entries during duplication and recurrence. ### After this commit: In Helpdesk, archived user are removed from new tickets when duplicated. In Planning, archived resources are excluded from new shift entries during duplication and recurrence. task-4419770
5 changes
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