Daily updates from Odoo
Navigate
Branch
Sunday, April 5, 2026
27 changes
6 changes
Enhancements to existing features
This update optimizes the installation process for the l10n_jo_edi module by preventing unnecessary calculations during initial setup. Specifically, a new field is created to store a unique identifier, avoiding delays caused by repeated computations on the database. This results in faster and smoother Odoo installations.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204 Forward-Port-Of: odoo/odoo#257748 Forward-Port-Of: odoo/odoo#257658
Resolved issues and error corrections
This update fixes an issue where unit of measure names (like 'm', 'l', 'g') couldn't be exported for translation. The change simplifies the filtering process to ensure these names are now included, resolving a translator's reported problem and improving the translation workflow. This ensures consistent and accurate translations across the Odoo system.
Original PR description
Single-letter strings (as used for units of measure, like `m`, `l`, `g`) are not exportable for translation, because the export of translation strings was filtering out different strings based on the type of the translation. This commit harmonized the filtering to the single condition of a string containing at least one letter, which allows exporting single-letter strings while still filtering out non-meaningful strings like `:`, `...`, `.00`, etc. Issue reported by one of our translators. Forward-Port-Of: odoo/odoo#257080
This update fixes an issue where newly created IAP account balances would reset to zero after saving the record. Now, the balance accurately reflects the selected service and remains correct even after the account is saved, improving the user experience. This ensures users see the correct IAP balance.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#257706 Forward-Port-Of: odoo/odoo#256589
This update significantly improves the speed and efficiency of loading product attributes on the shop page, especially when displaying a large number of products. The change optimizes how product information is retrieved, reducing memory usage and dramatically speeding up loading times. This results in a smoother and more responsive shopping experience for customers.
Original PR description
Before this commit, fetching product template attributes was slow and memory-intensive when handling a large number of products. The domain included IDs of all fetched products, leading to high memory usage and slow performance. To fix this, use the product domain directly instead of passing product IDs. Below is the performance comparison for the read_group used for attribute fetching: | Products | Before (Memory) | Before (Time) | After (Time) | | -------- | --------------- | ------------- | ------------ | | 900K | 113MB | 2.5s | 2ms | | 2M | 200MB | 7s | 2.5ms | | 9M | OOM | +15s (OOM) | 11ms | opw-5949132 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#256124
This update resolves an issue where applying inactive taxes in the Russian localization (l10n_in) module caused errors. The fix ensures that inactive tax IDs are handled correctly, preventing a traceback that could disrupt invoice processing. This improves the stability and reliability of the Russian tax calculations.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534 Forward-Port-Of: odoo/odoo#257754 Forward-Port-Of: odoo/odoo#256809
This update corrects a validation error that prevented users from being correctly linked to employees within the company. The issue stemmed from a miscalculation of employee IDs during user setup, particularly in a non-sudo environment. The fix ensures accurate employee linking by consistently performing searches within a sudo environment.
Original PR description
**Steps to reproduce** - Install `pos_hr` with demo data - Open Settings > Manage Users - Validation Error: A user cannot be linked to multiple employees in the same company **Cause** `employee_id`…
**Steps to reproduce** - Install `pos_hr` with demo data - Open Settings > Manage Users - Validation Error: A user cannot be linked to multiple employees in the same company **Cause** `employee_id` for the current user was computed as False here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L27 Despite an employee already existing, which led to the error here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L30 This exposes an issue with `_compute_company_employee`: - the compute is called a first time on multiple users, including the current user, in a non-sudo environment - the `employee_id` field for the current user is accessed in a sudo environment The problem comes from the search in non-sudo, which uses an `ir.rule` that evaluates `user.employee_id` in sudo while we are computing `user.employee_id`. **Fix** We avoid the cache issue by always performing the search in sudo. opw-6046297 Forward-Port-Of: odoo/odoo#256624
7 changes
Enhancements to existing features
This update optimizes the installation process for the l10n_jo_edi module by preventing a lengthy calculation from running automatically during module setup. This change avoids delays when Odoo is installed on systems with many existing account records, resulting in a faster and smoother installation experience.
Original PR description
This commit ensures that the computed and stored field `l10n_jo_edi_uuid` of account_move model gets column created at l10n_jo_edi module installation. This ensures that the computation of the field does not trigger on module installation, potentially leading to too slow installation if the DB has many account_move records. task-6095204 Forward-Port-Of: odoo/odoo#257748 Forward-Port-Of: odoo/odoo#257658
Resolved issues and error corrections
This update corrects errors in the generation of XML files for commercial events, ensuring accurate data transmission to the Dian authority. The fix addresses issues with naming conventions and QR code references, preventing rejection of submitted documents. This improves compliance and reduces potential delays in processing.
Original PR description
When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls _add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g. "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash: Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE. _dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's. We now render commercial events like how invoices are rendered. [1] odoo/enterprise#107170 opw-6065701 Forward-Port-Of: odoo/enterprise#112812
This update fixes an issue where single-letter unit of measure names (like 'm', 'l', 'g') couldn't be included in translations. The change simplifies the filtering process to ensure these names are now correctly exported, addressing a translator's reported problem and improving translation workflow efficiency.
Original PR description
Single-letter strings (as used for units of measure, like `m`, `l`, `g`) are not exportable for translation, because the export of translation strings was filtering out different strings based on the type of the translation. This commit harmonized the filtering to the single condition of a string containing at least one letter, which allows exporting single-letter strings while still filtering out non-meaningful strings like `:`, `...`, `.00`, etc. Issue reported by one of our translators. Forward-Port-Of: odoo/odoo#257080
This update fixes an issue where the IAP account balance would reset to zero after a record was saved. Now, the balance accurately reflects the selected service's value even after saving the account, providing a more reliable user experience. This ensures users always see the correct balance information.
Original PR description
Before this commit: When creating an `iap.account`, selecting a service(`service_id`) showed the correct balance. However, as soon as the record was saved, the balance would reset to 0, and users had to refresh the page to see the real value. With this fix, the balance now stays accurate after saving the record. Task [link](https://www.odoo.com/odoo/project.task/6004546) task-6004546 Forward-Port-Of: odoo/odoo#257706 Forward-Port-Of: odoo/odoo#256589
This update significantly improves the speed and efficiency of loading product attributes on the shop page, especially when displaying a large number of products. The change optimizes how product data is retrieved, reducing memory usage and dramatically speeding up loading times. This results in a smoother and more responsive shopping experience for customers.
Original PR description
Before this commit, fetching product template attributes was slow and memory-intensive when handling a large number of products. The domain included IDs of all fetched products, leading to high memory usage and slow performance. To fix this, use the product domain directly instead of passing product IDs. Below is the performance comparison for the read_group used for attribute fetching: | Products | Before (Memory) | Before (Time) | After (Time) | | -------- | --------------- | ------------- | ------------ | | 900K | 113MB | 2.5s | 2ms | | 2M | 200MB | 7s | 2.5ms | | 9M | OOM | +15s (OOM) | 11ms | opw-5949132 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#256124
This update resolves a technical error that prevented inactive TDS/TCS taxes from being correctly applied on invoices. The fix ensures that inactive tax calculations are handled properly, preventing errors and ensuring accurate tax reporting within the Odoo system. This improves the reliability of financial data for users of the Russian localization.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534 Forward-Port-Of: odoo/odoo#257735 Forward-Port-Of: odoo/odoo#256809
This update fixes a problem where PoS orders with additional products prevented successful settlement from the PoS. The system now correctly calculates the unpaid amount based on the total PoS order amount, ensuring sales can be settled properly even with multiple items. This resolves a previous issue impacting payment processing.
Original PR description
The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232 Forward-Port-Of: odoo/odoo#256590 Forward-Port-Of: odoo/odoo#251387
1 change
Resolved issues and error corrections
This update ensures that account moves are automatically created when closing a POS session containing paid future orders from Urban Piper. Previously, these orders were excluded, preventing proper accounting record generation. This change improves financial reporting accuracy for orders processed through the Urban Piper integration.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#112749 Forward-Port-Of: odoo/enterprise#111137
6 changes
Resolved issues and error corrections
This update fixes an issue where unit of measure names (like 'm', 'l', 'g') couldn't be exported for translation. The change simplifies the filtering process to ensure single-letter strings are now included, resolving a translator's reported problem and improving translation workflow efficiency.
Original PR description
Single-letter strings (as used for units of measure, like `m`, `l`, `g`) are not exportable for translation, because the export of translation strings was filtering out different strings based on the type of the translation. This commit harmonized the filtering to the single condition of a string containing at least one letter, which allows exporting single-letter strings while still filtering out non-meaningful strings like `:`, `...`, `.00`, etc. Issue reported by one of our translators. Forward-Port-Of: odoo/odoo#257080
This update fixes an issue where users were incorrectly prompted for passwords when downloading encrypted documents that didn't actually require them. The change now accurately checks if a password is needed before attempting a download, ensuring a smoother and more reliable experience for users accessing signed documents. This resolves a previously blocked download flow.
Original PR description
Related ticket: https://www.odoo.com/odoo/project/49/tasks/5400441 Previously, if a user went to download a document, we would check if it was encrypted. If so, we would redirect to ask for a password. But the problem with that is, not all encrypted documents require passwords. In that case, we would ask for a password when none existed, thus blocking the user from downloading the document. Now we check if a password is required to access the document instead of whether the document is encrypted. That way, we won't redirect to ask for a password when there is no password. Forward-Port-Of: odoo/enterprise#112220 Forward-Port-Of: odoo/enterprise#102602
This update resolves a technical error that prevented inactive TDS/TCS taxes from being correctly applied when generating invoices. The fix ensures that inactive tax calculations are handled properly, preventing errors and improving the accuracy of tax reporting for Indian businesses. This change was made to ensure compliance and reliable financial reporting.
Original PR description
Before this **PR**, attempting to apply an inactive tax resulted in a traceback. This occurred because l10n_in_section_tax_ids was empty, resulting in an empty iterable being passed to max(), which caused the error. To resolve this issue, l10n_in_section_tax_ids is now called with the context `active_test=False`. task-6074534 Forward-Port-Of: odoo/odoo#257724 Forward-Port-Of: odoo/odoo#256809
This update ensures that account moves are automatically created when closing a POS session with Urban Piper orders, regardless of payment status. Previously, only unpaid future orders triggered account moves. This change corrects a bug that prevented proper accounting record generation for all Urban Piper orders, improving financial reporting accuracy.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#112749 Forward-Port-Of: odoo/enterprise#111137
This update ensures the Danish localization of Odoo accurately reflects the latest tax regulations and translations provided by the Danish tax authorities. It streamlines the process by automatically updating account groups and translations, improving data accuracy and compliance for Danish businesses.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257725 Forward-Port-Of: odoo/odoo#256541
This update improves the accuracy of Danish balance sheet and profit and loss reports by aligning with Danish accounting standards and simplifying report formatting. Specifically, the reports now use account names directly as sublines, streamlining the presentation of financial data and ensuring correct translations for Danish and English.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113057 Forward-Port-Of: odoo/enterprise#112430
1 change
Resolved issues and error corrections
This update ensures that account moves are automatically created when closing a POS session containing Urban Piper future orders (orders with a delivery date). Previously, these orders were excluded, preventing proper accounting record generation. This change ensures accurate financial reporting for orders processed through the Urban Piper integration.
Original PR description
Before this commit, when all orders coming from Urban Piper in a POS session are paid future orders (i.e. have a delivery_datetime), closing the session would not generate an account move. The cause was that the code was excluding future orders when creating the account move. The fix is to exclude only unpaid orders instead. How to reproduce: - Set up Urban Piper (a test account needed). - Place an order from the Urban Piper platform. - Receive the order, accept it, and mark it as ready. - Close the session. - The session will not have an account move. opw-5995985 Forward-Port-Of: odoo/enterprise#111137
4 changes
Resolved issues and error corrections
This change updates URLs used for testing Wise direct deposit integrations to the new wise-sandbox.com domain. Wise is phasing out their old sandbox, so this update ensures continued functionality and avoids disruptions to payment testing. Users may need to create a new sandbox account, but the impact is expected to be minimal.
Original PR description
Wise is deprecating their legacy sandbox (sandbox.transferwise.tech) in June 2026. Replace all sandbox URLs with the new wise-sandbox.com domain to avoid breaking test/sandbox payment flows. - API: api.sandbox.transferwise.tech → api.wise-sandbox.com - Portal: sandbox.transferwise.tech → wise-sandbox.com Note: API keys from the legacy sandbox are not transferable to the new environment. Affected users will need to create a new sandbox account, though the impact should be minimal as most customers do not actively use the sandbox. task-6074132 Forward-Port-Of: odoo/enterprise#112921
This update adds a specific line item for Treasury Shares (account 2980) to the CH balance sheet report. Previously, this account was handled differently, and this change ensures accurate reporting of equity, reflecting a necessary correction. The update improves the clarity and accuracy of financial reporting for Swiss clients.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108
Forward-Port-Of: odoo/enterprise#111302This update fixes an access error within the Frontdesk module that prevented users with limited employee permissions from creating new stations or visitors. The issue stemmed from a requirement to inherit `hr.mixin` in models using `hr.employee` many2many fields. This change ensures proper access control and functionality for Frontdesk users.
Original PR description
Issue: ---------------------------------------- When a user with administrator rights on frontdesk but no rights on employees try to create a new station or visitor, they get an access error. Steps to reproduce: ---------------------------------------- - Have a user with administrator rights on Frontdesk but no rights on Employees - Switch to this user - Open Frontdesk and try to create a new station - Access Error Cause: ---------------------------------------- Since [this commit](https://github.com/odoo/odoo/commit/71f662b827b58c4f8ed1260728dc5194201ec323) models having a many2many field on `hr.employee` must inherit from `hr.mixin` to avoid an access error. The Frontdesk module was not changed. Solution: ---------------------------------------- Make `frontdesk.visitor` and `frontdesk.frontdesk` inherit `hr.mixin` opw-6000417 Forward-Port-Of: odoo/enterprise#112893 Forward-Port-Of: odoo/enterprise#110084
This update corrects errors in the generation of XML files for commercial events, ensuring compliance with Dian regulations. Previously, incorrect naming conventions and UUID extraction led to rejected transactions. The fix standardizes XML rendering to match invoice formats, resolving these issues and improving data accuracy.
Original PR description
When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went…
When POS support was added [1], XML rendering was refactored to use dict_to_xml. Commercial events were partially migrated: the body used the new mechanism, but extensions and signing still went through the deprecated _dian_sign_xml(). That method calls _add_invoice_config_vals() which sets vals['name'] to invoice.name (e.g. "BILL/2026/0001"). For commercial events the name should be the event ID (e.g. "SETP9900130771"). SoftwareSecurityCode is computed as sha384(software_id + security_code + name), so the wrong name produced a bad hash: Regla: AAB27b, Rechazo: Huella no corresponde a un software autorizado para este OFE. _dian_sign_xml() also extracted uuid from the rendered XML's <cbc:UUID/>, which is the event's own CUDE. But the QR code should reference the original invoice's CUFE, not the event's. We now render commercial events like how invoices are rendered. [1] odoo/enterprise#107170 opw-6065701 Forward-Port-Of: odoo/enterprise#112973 Forward-Port-Of: odoo/enterprise#112812
2 changes
Resolved issues and error corrections
This update fixes an issue where single-letter unit of measure names (like 'm', 'l', 'g') couldn't be included in translations. The change simplifies the filtering process to ensure these names are now correctly exported, addressing a translator's reported problem and improving translation workflow efficiency.
Original PR description
Single-letter strings (as used for units of measure, like `m`, `l`, `g`) are not exportable for translation, because the export of translation strings was filtering out different strings based on the type of the translation. This commit harmonized the filtering to the single condition of a string containing at least one letter, which allows exporting single-letter strings while still filtering out non-meaningful strings like `:`, `...`, `.00`, etc. Issue reported by one of our translators. Forward-Port-Of: odoo/odoo#257080
This update resolves an issue where tests weren't correctly running when a class included the `-standard` designation. The change ensures that all tests, regardless of this designation, execute properly, improving the reliability of our testing process. This ensures consistent and accurate test results.
Original PR description
Closes [#256517](https://github.com/odoo/odoo/issues/256517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr