Saturday, April 4, 2026
8 changes · saas-19.2
Resolved issues and error corrections
This update fixes an issue where amounts with thousand separators (like 1,334.00) were incorrectly interpreted, leading to potential errors in reconciliation reports. The change introduces a new function to intelligently parse these amounts, ensuring accurate calculations and reporting. This improves the reliability of financial data.
Original PR description
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to…
When extracting amounts using a regex with a single capturing group, values containing thousand separators such as 1.334,00 or 1,334.00 were not correctly converted to floats. This could lead to incorrect amounts being interpreted in reconciliation models.
Added a new function `split_amount_str`in utils which will give
integer and decimal part for different number formats.
This is a heuristic approach, meaning it aims to provide the best
possible result for valid inputs. Invalid or ambiguous formats are
not guaranteed to be parsed correctly and may result in ('0', '0').
For the two capturing groups case, the first group is treated as the
integer part and the second as the decimal part, allowing users to
Explicitly split amounts like 9065 into 90.65 by using two groups
in their regex.
Examples:
EU format: 1.334,15 → 1334.15
US format: 1,334.15 → 1334.15
Implicit decimals: uid 01870912 0000009065 → 90.65 (using two groups)
Additional tests were added to ensure amounts with thousand separators
are correctly parsed.
Task [link](https://www.odoo.com/odoo/project/967/tasks/6026748)
task-6026748
Forward-Port-Of: odoo/enterprise#110410This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change ensures correct equity reporting for Swiss GAAP compliance. The change improves the accuracy of financial reporting.
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 improves how the "My Team" filter works in Live Chat agent reports. Instead of grouping by department, the system now uses a manager-based hierarchy to show each agent their own records plus records of employees they directly manage. This provides a more accurate and intuitive view of team performance data.
Original PR description
Replace the department-based domain with a hierarchy-based domain. The new filter includes the current user's records and the records of employees whose manager is the current user. follow-up of https://github.com/odoo/odoo/pull/253567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257548
This fix prevents files from becoming orphaned when an error occurs during file upload. Previously, if a file write operation failed (due to disk space or permission issues), the system wouldn't clean up the incomplete file, causing it to take up disk space and block future uploads of the same file. Now the system properly marks files for cleanup before attempting to write them, ensuring failed uploads don't leave behind problematic files.
Original PR description
If an error occurs during the file write operation, the file will not be marked for garbage collection, which can lead to orphaned files taking up disk space or blocking other same file to be written. Step to reproduce the issue: 1. Create an attachment with a large file (e.g., 100MB) and save 2. During the file write operation, simulate an IOError (e.g., by filling up the disk space or changing file permissions) 3. The file will not be marked for garbage collection, and it will remain 4. Further attempts to create this same attachment will result in error: "The attachment collides with an existing file." opw-6055037 opw-5907025 Forward-Port-Of: odoo/odoo#257384 Forward-Port-Of: odoo/odoo#257274
This fix resolves a problem where copying and pasting text in the website builder was incorrectly creating paragraph elements in areas that shouldn't contain them, such as buttons and footer text. The fix allows inline elements to remain inline in these special areas instead of being wrapped in paragraph tags, improving the editing experience and preventing unwanted formatting changes.
Original PR description
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p`…
Since [website builder refactor], the editor wraps inline elements at the root of an editable boundary. This is causing issues in website builder when the root element is not supposed to contain `p` or `div` elements (added to wrap the inline elements). This behavior can be configured globally with `allowInlineAtRoot`. And since 6bc5946796a364634cb5eb217e61a5b882a1b6b2, it can be configured per-element with a "predicate" resource. This commit adds a predicate to allow inline at root of editable when the root is (according to its tag) not supposed to contain `p` or `div` elements. Steps to reproduce: - Open website builder on a product page - Select text in "Add to cart" button - Copy - Paste - Bug: a `p` element is created (on master) - Open website builder - Select "Company" below footer - Copy - Paste - Bug: a `p` element is created [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5868460 Forward-Port-Of: odoo/odoo#257512 Forward-Port-Of: odoo/odoo#247231
This fix resolves a problem where POS orders created in Jordan before installing the EDI module could not be submitted to JoFotara due to missing unique identifiers. The system now automatically generates the required order identifier when needed, ensuring all orders can be successfully submitted regardless of when they were created.
Original PR description
Currently, POS orders in Jordan do not have a UUID if they were created before installing the module. This causes submission failures to JoFotara. Steps to reproduce: - Create a POS order in Jordan without the module l10n_jo_edi_pos installed - Install l10n_jo_edi_pos - Try to submit the order to JoFotara, it fails due to missing UUID with the error "Invoice UUID is required" This fix force a computation of the order UUID when we add the header node, to ensure that this will not cause submission failures to JoFotara. opw-6041688 Forward-Port-Of: odoo/odoo#255996
This fix ensures that when users send multiple Request for Quotations (RFQs) using the bulk "Send by mail" action, the RFQ status is automatically updated to "Sent" - just like it does when sending individually from the form view. Previously, RFQs would remain marked as "Draft" even after being emailed, causing confusion and requiring users to resend them to update the status.
Original PR description
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them…
Issue Before This Commit: ======================= When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users. Steps to Reproduce: ======================= - Install the `Purchase` app. - Go to Purchase and select multiple RFQs in the list view. - Click `Send by mail` from the actions menu. - Select the RFQ email template and send the email. - Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view. Cause of the issue: ======================= The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated After This Commit: ======================= When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state. TaskID-5443248 Forward-Port-Of: odoo/odoo#243050
This update improves how the system reports errors when email templates fail to render. Instead of showing entire template code in error messages and logs, it now displays only relevant snippets while identifying which template caused the problem. This reduces unnecessary log clutter and makes it easier for support teams to diagnose and fix template issues.
Original PR description
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a…
This is mainly a backport of an IMP done at https://github.com/odoo/odoo/pull/252455 Given it's potential to reduce server bloat and increase of QOL for sys admins and support agents, backporting (a sligthly modified version) seemed adequate. Summary: When a QWeb template fails to render, the current logic logs the entire template source and raises a generic UserError. This leads to significant log bloat and makes it difficult for developers and support staff to identify the specific failing template or the root cause of the error. This commit improves the error handling in `mail.render.mixin` and `mail.template` by: - mail.render.mixin: Added logic to identify the failing template's name and ID if it belongs to a `mail.template` or `mail.compose.message` (mass mailing). - Log Truncation: Implemented truncation for identified templates, showing only a snippet (first and last 500 chars) in logs and UserErrors to prevent log/UI bloat while keeping full source logging as a fallback for unidentified templates. OPW-5980295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257359 Forward-Port-Of: odoo/odoo#257104