Daily updates from Odoo
Wednesday, February 25, 2026
10 changes · master
Resolved issues and error corrections
This update simplifies how Odoo identifies part-time workers. Previously, a worker exceeding their contract hours was incorrectly categorized as part-time. This change clarifies the definition by using 'work_time_rate' to accurately reflect actual hours worked, improving payroll accuracy and reporting.
Original PR description
Previously , 'is_full_time' indicated just if the worker , has worked the exact amount in his contract or less , but it has a problem, for workers who worked more than there legal contract, They were also considered on Part Time. For the sake of simplicity and clarity, instead of adding a new field like "excess Time", it would be better to just precise the work_time_rate.
This update resolves a previous issue where automation flows involving moving documents and triggering subsequent actions often failed due to security restrictions. The change now allows actions to run seamlessly even after a document is moved, simplifying automation setup for users. The fix also removes a redundant security override, streamlining the system.
Original PR description
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security…
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security check required the sub-action to be explicitly embedded (pinned) on the *destination* folder. Since the record was moved during the process, the subsequent action failed the security check on the new folder where it wasn't pinned. This limitation caused confusion for users setting up automation flows, as the intent of the sequence (Move -> Action) was clear and initiated from a valid context (the source folder), but strict per-action security rules blocked execution. This commit improves the `ir.actions.server` execution logic to support this pattern by introducing a context-based security sentinel: 1. Entry Point Validation: When a Documents action (root) is triggered, the system enforces strict security: the action must be explicitly embedded on the record's current folder. 2. Context Inheritance: Once the root action is authorized and begins execution, it sets a secure sentinel in the context. 3. Trusted Execution: Any subsequent sub-actions (children) detect this sentinel and are allowed to run, regardless of the record's current folder location. This ensures that if a user has the right to start the process (the root action), they have the right to complete the defined sequence, even if intermediate steps move the record to a folder where the sub-actions are not explicitly pinned. As a result, the `_can_execute_action_on_records` override in `documents_account` is no longer necessary and has been removed. Tests have been extended in the `documents` and `documents_account` modules to cover these scenarios (using Tags in the `documents` module instead of Accounting-specific models to make the tests generic). A new test file `test_documents_ir_actions_server.py` was created to maintain a clean testing environment, covering nesting, move sequences, and RPC spoofing attempts. Task-5916630 Forward-Port-Of: odoo/enterprise#108204 Forward-Port-Of: odoo/enterprise#106702
This update resolves an issue where Odoo incorrectly defaulted to USD as the Stripe currency, causing potential blocking for EU companies with non-USD currencies. We've switched to EUR as the default, ensuring accurate Stripe integration and preventing disruptions for our European users. This change addresses previous support tickets (opw-5393508, opw-5913327, opw-5953025).
Original PR description
Right now, we need to guess the correct stripe currency for the stripe account depending on the country, we used the USD as an ultimate fallback But, the USD currency is easy to guess, where the EUR is way harder (it may not be the company currency). So, it is too error-prone to set the USD as the default fallback, and it can lead to EU companies being blocked as their stripe currency is the wrong one. We therefore switch it to EUR. opw-5393508 opw-5913327 opw-5953025 Forward-Port-Of: odoo/enterprise#108293
This update improves the speed of changing order stages in the Point of Sale system. By separating customer display calculations and optimizing database queries, the process is now significantly faster, especially when multiple orders are being prepared. This enhances the user experience and overall system performance.
Original PR description
Before this commit when a lot of orders were in the preparation display and when clicking on an order to change its stage, it was very slow because we were doing the customer display computation directly. Now we compute customer display data in a separate RPC call, and we only call it when the customer display receives a notification of new orders, which makes the stage change much faster. The `_get_pos_orders` is updated to avoid an O(n²) loop; The `_get_open_orderlines_in_display` is updated to avoid deep joins. Forward-Port-Of: odoo/enterprise#108233 Forward-Port-Of: odoo/enterprise#107727
This update enhances how Odoo extracts amounts from bank statements (like CODA files). It now supports regex patterns that identify integer and fractional parts, allowing for accurate decimal amount recognition. This resolves an issue where amounts in cents were not correctly processed, improving the reliability of reconciliation processes.
Original PR description
Update the reconciliation logic of reco models to support regex patterns using named capture groups 'integer' and 'fraction'. This is specifically designed for cases where bank statement labels (like CODA files) provide amounts in cents i.e continuous string of digits without a decimal separator. The logic now: - Prioritizes 'integer' and 'fraction' named groups if present in the match. - Concatenates these groups with a decimal point to form a valid float. - Falls back to the standard digit extraction logic if named groups are not found. So now if user wants the amount to be extracted in decimal values from label then user needs to add regex which supports two groups 'integer' and 'fraction'. Community PR: odoo/odoo#242750 Task [link](https://www.odoo.com/odoo/project.task/5449413) Task-5449413 Forward-Port-Of: odoo/enterprise#108328 Forward-Port-Of: odoo/enterprise#103630
This update fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice data sent to the Ecuadorian tax authority (SRI) uses the correct, officially mandated terminology. This ensures compliance and avoids potential processing delays.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update reverses a recent change that was incorrectly removing accented characters from partner names used for Mexican VAT (EDI) processing. The system now correctly accepts the accented characters the user inputs, aligning with current SAT regulations. This ensures accurate processing and avoids blocking users from entering legally required name information.
Original PR description
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least…
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]). This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues. The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them. This reverts the whole accent sanitization saga: - Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4. This also removes the unused frozendict import to make "Check Style" happy. opw-5915515 [1] https://github.com/odoo/enterprise/pull/95207 [2] https://github.com/odoo/enterprise/pull/107960 [3] https://github.com/odoo/enterprise/pull/96043 [4] https://github.com/odoo/enterprise/pull/106557 [5] https://github.com/odoo/enterprise/pull/107677 Closes odoo/enterprise#107960 Forward-Port-Of: odoo/enterprise#108425 Forward-Port-Of: odoo/enterprise#108189
This update corrects a recent issue that prevented Invoicing and Banks users from accessing basic financial reports. The change restores the necessary permissions, ensuring these users can view critical reporting data without errors. This resolves a disruption to key business reporting functionality.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108174 Forward-Port-Of: odoo/enterprise#107654
This update fixes a critical issue where mandatory fields were incorrectly included in signature validation, forcing users to sign them. Now, automatic completion is enabled for these fields, and a clear placeholder is used when the auto-field is empty, improving the user experience and data accuracy.
Original PR description
Before this commit, constant required sign fields with auto_fieldwere incorrectly included in signature validation, forcing users to sign them. Additionally, when auto_field had no value, these fields remained empty instead of using placeholder text as fallback. After this commit, constant required fields are excluded from signature validation, allowing automatic completion. When auto_field returns no value, the placeholder or item type name is used, providing a more clear and informative fallback content for users. task-5886200
This update ensures payslips accurately reflect an employee's actual start date with the company, regardless of internal job changes. Previously, payslips used the contract start date, which wasn't ideal for employees with multiple periods of employment. This change improves payroll accuracy and reporting, particularly in Switzerland and the UAE.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#108145 Forward-Port-Of: odoo/enterprise#106692