Daily updates from Odoo
Navigate
Branch
Wednesday, May 27, 2026
271 changes
27 changes
Resolved issues and error corrections
This update resolves a problem where icon assets (like `.woff2`) weren't loading correctly, causing errors. The fix ensures that asset versions are handled consistently, preventing mismatches and improving the display of icons on the website. This improves the user experience by ensuring all icons load properly.
Original PR description
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to…
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to produce: - Install website - Open page `/web/assets/1/6a783c3/web.odoo_ui_icons.min.woff2` Error: `UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value` This issue occurs because the code at [1] compares `binary.extension` with `asset_type`, causing the condition to fail because `binary.extension` contains values such as `woff` or `woff2`, while `asset_type` is set to `'binary'`. The root cause is that `asset_type` with value `'binary'` is being passed as a parameter to the `bundle.get_link` method (see [2]). The `asset_type` value comes from the `_parse_bundle_name` method (see [3]), where it is set to `'binary'` whenever the file extension belongs to `BINARY_EXTENSIONS`, such as `woff` or `woff2` (see [4]). This commit fixes the inconsistency between `bundle.get_version()` and `bundle.get_link()` when `binary` is `True`. Currently, `bundle.get_version()` used `extension if binary else asset_type`, while `bundle.get_link()` always received `asset_type`. This could lead to an incorrect redirect when handling binary assets. The fix normalizes the value by updating `asset_type` beforehand and reusing it consistently in both `bundle.get_version()` and `bundle.get_link()`. This also improves readability by removing the inline conditional expression. [1]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/assetsbundle.py#L166 [2]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/addons/web/controllers/binary.py#L146 [3]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/ir_asset.py#L93-L94 [4]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/tools/constants.py#L6-L7 Sentry-7441025709 Forward-Port-Of: odoo/odoo#263506
This update corrects a bug that prevented users from creating bank accounts with certain proxy values (CPF/CNPJ or Random Key). The issue stemmed from incorrect data types being passed to validation functions, causing an error. This fix ensures bank account creation processes smoothly for all users.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266243 Forward-Port-Of: odoo/odoo#264995
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This improves financial reporting accuracy.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#117457 Forward-Port-Of: odoo/enterprise#114590
This update resolves a bug in the HTML Editor that caused crashes when users removed tables while resizing. The fix restricts resizing to the primary mouse button and prevents the editor from running resize logic when no target is available, improving stability and preventing unexpected errors.
Original PR description
#### Description of the issue this PR addresses: - Table resize listeners are not cleaned when the table is removed while resizing - Next mousemove runs resize logic with a null target and throws traceback #### Desired behavior after PR is merged: - Restrict resize start to primary mouse button only - Prevent resize logic execution on null targets #### Steps to reproduce: - Open the todo app - Insert a table and select whole table - Move cursor on a table cell border to see resize cursor - Right click and choose Cut from browser context menu - Move the mouse again - Resize logic crashes with null target traceback task-6212279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266274 Forward-Port-Of: odoo/odoo#264065
This update fixes a problem where invoices with year-range invoice numbers wouldn't send correctly to MyInvois. The change ensures the system correctly processes these invoice numbers, allowing invoices to be successfully transmitted for accounting purposes. This resolves a disruption in the automated invoice submission process.
Original PR description
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi`…
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi` modules (with demo data). 2. Switch to "MY Company"(Malaysian company). 3. Enable "_Quick Encoding_" for Customer Invoices in Settings. 4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice. 5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again. 6. Open the invoice list view and click **"Send to MyInvois"**. **Error:** `ValueError: not enough values to unpack (expected 4, got 2)` The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1]. [1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146 Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263 sentry-7320998540 Forward-Port-Of: odoo/odoo#266221 Forward-Port-Of: odoo/odoo#253237
This update fixes an issue where the template name wasn't correctly displayed after selecting a template using the 'Search More' feature in the employee form. The fix ensures that the correct template label is shown, improving the user experience when loading templates. This prevents users from seeing 'Unnamed' and ensures accurate template selection.
Original PR description
Version: - saas-19.1 Steps to reproduce: - Open an employee form. - Click "Load a Template". - Use "Search More" and select a template. Issue: - The selected template label is displayed as "Unnamed" after selecting a template from the search view. Cause: - When selecting a record through "Search More", the returned value only contains the record `id` and does not include `display_name`. As a result, the many2one field cannot render the correct label and falls back to "Unnamed". Fix: - Perform an ORM read to fetch the missing `display_name` using the selected record id, then update `selectedTemplate` with the complete value so the correct template name is displayed. Task-6186635 Forward-Port-Of: odoo/odoo#264556
This update fixes an issue where the End Balance columns in the Romanian Trial Balance reports were displaying incorrect totals when the report hierarchy was enabled. The fix eliminates double-counting of account groups, ensuring accurate and consistent financial reporting for Romanian businesses using Odoo Enterprise.
Original PR description
### Issue before this commit: The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled. ### Steps to reproduce the issue: 1. Downaload Accounting and l10n_ro 2. Switch to RO company 3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals 4. See that the End Blance both debit and credit is not correct ### Cause of the issue: The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting. ### Reason to introduce the fix: To eliminate group double-counting and providing consistency with the totals in all the trial balances reports. opw-6146200 Forward-Port-Of: odoo/enterprise#118080 Forward-Port-Of: odoo/enterprise#117855
This update ensures that accounting reports accurately reflect reconciled transactions even after a reconciliation is removed. Previously, leftover data caused incorrect display of reconciled items. This fix cleans up the system to prevent misleading reporting and maintain data integrity.
Original PR description
### Description `account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default…
### Description
`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.
This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.
### Steps to reproduce
A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:
```python
company = env.ref('base.main_company') # USD company
partner = env['res.partner'].create({'name': 'demo'})
# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
{'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
{'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])
inv = env['account.move'].create({
'move_type': 'out_invoice', 'partner_id': partner.id,
'currency_id': env.ref('base.EUR').id,
'invoice_date': '2026-01-15', 'date': '2026-01-15',
'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()
env['account.payment.register'].with_context(
active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()
recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)
full.unlink() # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False # FAILS without this PR
assert not recv.full_reconcile_id
```
Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.
### Diagnostic query
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
])
```
Returns lines in the orphan state on any database.
### Impact
Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.
### Tests
`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`
### Linked
* Bug report: closes #264790
The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
]).write({'matching_number': False})
env['account.full.reconcile'].search([
('reconciled_line_ids', '=', False),
('partial_reconcile_ids', '=', False),
]).unlink()
```
Forward-Port-Of: odoo/odoo#264805This update ensures a more visually appealing and consistent look for the HTML Builder by aligning the accent colors used in buttons with the text colors. Previously, the text colors had a weaker contrast, now they match the button styles for better readability and a polished design.
Original PR description
In the html builder, we use strong, neon colors especially for the `btn-success` and `btn-danger`. However, the tint for `text-succes` / `text-danger` was duller, with a bad contrast against the background. This commit simply uses the same color, within builder buttons, for the text classes accent colors as for the btn classes. Forward-Port-Of: odoo/odoo#262277
This update fixes an issue where long task names in the calendar's 'to schedule' panel would overflow, making it difficult to read. Now, task names are automatically truncated with an ellipsis when they are too long, ensuring a cleaner and more user-friendly experience.
Original PR description
**Before this commit:** Task names in the "to schedule" side panel of the Calendar view were not truncated, causing them to overflow their container when the name was too long. **After this commit:** Task names in the "to schedule" side panel are now properly truncated with an ellipsis when they exceed the available width. task-6237072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266018
This update fixes a visual issue where the reply composer remained visible after a live chat conversation ended or a channel became read-only. Now, the composer automatically disappears when replying is no longer possible, ensuring a cleaner and more consistent user experience. This improves usability and prevents confusion.
Original PR description
***=im_livechat** **Steps to Reproduce: [Livechat case]** - Start a Live Chat conversation between an Operator and a Visitor. - From the operator side, click Reply on a visitor message. - From the…
***=im_livechat** **Steps to Reproduce: [Livechat case]** - Start a Live Chat conversation between an Operator and a Visitor. - From the operator side, click Reply on a visitor message. - From the visitor side, close the conversation. - Return to the operator side. - Observe that the replyToMessage composer is still visible even though the live chat has ended. **[Channel Read-only case]** - Create a channel between two users. - Ensure the channel is writable initially. - From one user's side, click Reply on another user's message. - While the user is in reply mode, make the channel read-only from the admin side. - Return to the replying user's side. - Observe that the reply-to-message composer is still visible even though the channel has become read-only. **Current behavior before PR:** Before this PR, the reply composer could remain visible after the conversation became unavailable for replying, such as when a channel turned read-only again or when a livechat conversation ended. **Desired behavior after PR is merged:** After this PR, the reply composer is automatically dismissed whenever replying is no longer possible, keeping the composer state consistent with the conversation state. task-[6208973](https://www.odoo.com/odoo/project/1519/tasks/6208973) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265487
This update simplifies the process of adding bank journals in Odoo. Previously, users needed to immediately provide a bank account number via the Odoofin iframe. Now, the system handles this more flexibly, allowing for account number entry later or creating the journal directly if all required data is available.
Original PR description
Previously, when adding a bank journal via the Odoofin iframe, the bank account number was strictly required. Starting from version 19.2, bank journals can no longer be created from the standard form view. This change forces users to provide an account number immediately via the iframe, even if they intended to synchronize it later. While the form view restriction is a 19.2 change, this improvement is applied to 17.0 because the Odoofin iframe is shared across versions. This is resolved across both environments with the: - Odoofin commit: The account number requirement is removed from the iframe. - Enterprise commit: If the account number is missing, the system no longer returns a setup wizard. It creates the bank directly if all required data is available; otherwise, it creates the journal without an account number. task-6072798 OdooFin PR: https://github.com/odoo/odoofin/pull/539 Forward-Port-Of: odoo/enterprise#112506
This update fixes several issues identified by Runbot during testing of the restaurant POS module. Specifically, problems related to order identification and refund processing were addressed, preventing disruptions to the checkout and payment flow. The changes include safety measures like optional order ID handling and improved tour navigation.
Original PR description
Runbot failed in three cases: taxGroupLabels could run while order_id was missing and crash on fiscal_position_id. During sync, is_refund on the order could disagree, so _askForPreparation showed the kitchen prompt on refund flows and blocked payment. The delete-line tour sometimes asserted before the table was closed; the tour now opens the plan again to close and sync tables. Safety fix: Optional chaining on order_id; Wait for sync refund for the preparation check; Explicit plan navigation in the tour. runbot error - 242601-242604 Forward-Port-Of: odoo/odoo#260264
This update fixes a translation issue within the HTML editor's 'move' tooltip. Previously, tooltips weren't displaying translated text due to a technical limitation in how the editor processed templates. This change ensures all tooltips are correctly translated for users, improving the overall user experience.
Original PR description
Currently the move tooltip in the HTML editor is not translated because the exporter can't see `_t()` calls in tagged template literal. This commit fixes the issue by moving the call outside of the template literal. Forward-Port-Of: odoo/odoo#266233 Forward-Port-Of: odoo/odoo#265991
This update resolves an issue preventing correct data handling with Odoo v19.0 databases. Specifically, it ensures the 'owner' key is included in event notifications, and it also corrects a bug where old session data was not being properly cleared, improving overall system performance.
Original PR description
For compatibility with v19.0 db, we need to keep the owner key in lp events. We do have them in the action direct response thanks to the `handle_message` base response message, but this is not forwarded to the event route. We also take the opportunity to fix the session cleaning, which was keeping only old sessions instead of newer ones. Forward-Port-Of: odoo/odoo#266377
This update increases the timeout for printing large documents, resolving an issue where documents taking longer than 30 seconds to print would fail. By extending the timeout to 90 seconds, users can now successfully print larger files without interruption. This enhances the overall printing experience.
Original PR description
To allow printing large documents that take more than 30 seconds to print, we increase the timeout to 90 seconds. opw-6235827 Forward-Port-Of: odoo/odoo#266005
This update resolves a technical issue where email server configuration records would fail if no authentication details were provided. The fix ensures that all records are processed correctly, preventing errors and improving the reliability of email functionality. This change enhances the stability of the system.
Original PR description
Description of the issue/feature this PR addresses: The compute method for `smtp_authentication_info` did not properly handle cases where no `smtp_authentication` value was set. Current behavior before PR: * When `smtp_authentication` was empty or had an unsupported value, `smtp_authentication_info` was never assigned. * This caused the compute method to fail with: `ValueError: Compute method failed to assign ir.mail_server(...).smtp_authentication_info` * As a result, reading or displaying the record could raise an exception. Desired behavior after PR is merged: * The fallback branch explicitly resets `smtp_authentication_info`. * `smtp_authentication_info` is always assigned during computation. * Records without an authentication method no longer raise compute errors and are handled correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266411
This update resolves an issue where the system incorrectly flagged deductions on receipts, potentially preventing users from accurately recording expenses like self-employed individuals. The change ensures that deductions on receipts are now properly processed, aligning with common accounting practices. A new test has been added to verify this functionality.
Original PR description
As using deductions on receipts is a plausible accounting situation, such as in the case of self-employed person booking a ticket, there shouldn't be a validation error raised in this case. task-6037582 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254371
This update fixes an issue where portal messages were incorrectly restricted, preventing access to certain message types. The change ensures all non-internal messages are visible while still hiding internal notes as intended. This improves user experience and data accessibility within the portal.
Original PR description
*: test_mail_full Since #138233, portal messages were strictly filtered by the `mt_comment` subtype. This was intended to hide internal notes, but it incorrectly excluded other non-internal message subtypes. Basically we want the share domain (`_get_search_domain_share()`) to apply to all users in the portal. This change ensures internal notes remain hidden while allowing all other non-internal non-comment subtypes to be visible. opw-6031571 Forward-Port-Of: odoo/odoo#265096 Forward-Port-Of: odoo/odoo#263052
This update corrects a restriction in the Recruitment app where Interviewer users could view talent pools but lacked the ability to manage applicants or create new pools. The fix addresses a security rule preventing access, aligning with the intended role limitations for Interviewers.
Original PR description
## Issue In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the…
## Issue
In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the applicants within the pools, and cannot create new pools either.
## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) with demo data
2. Set Marc Demo's *Recruitment* role to *Interviewer*
3. As Marc Demo, navigate to Recruitment > Applications > By Talent Pools
4. **We can see the existing pools, but they all appear empty ("0 Talents"), and we cannot add talents to a pool, nor create new pools.**
## Cause
Interviewer do not see any applicants in the talent pools because of the following rule:
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/hr_recruitment/security/hr_recruitment_security.xml#L48-L60
In fact, applicants in talent pools do not have a job_id set:
```sql
190=# SELECT a.partner_name, a.job_id FROM hr_applicant a
190-# JOIN hr_applicant_hr_talent_pool_rel tpr
190-# ON (tpr.hr_applicant_id=a.id);
partner_name | job_id
---------------+--------
Cameron Ellis |
Ethan Carter |
Noah Bennett |
Test Talent |
(4 rows)
```
This leads to no applicants being shown to the interviewers in the talent pools.
## Justification
Interviewers by default only have access to applications who they are interviewer for, it is not intended for them to see entire pools of potential candidates. Letting interviewers access the talent pools view is counter-intuitive, as they have nothing they can do from there.
opw-6187187
Forward-Port-Of: odoo/odoo#265812This update enables payment provider settings to be duplicated when a branch company is created. Previously, this was restricted due to accounting practices, but now it's supported to align with the option to use journals in branch companies. This simplifies setup and management of payments across our business locations.
Original PR description
This PR will allow payment providers to be duplicated into branch companies when a branch company is created. Previously this was prevented because in accounting it's preferred not to use journals in branches. However, there it is still possible to setup a journal in branches. So it makes sense to allow it also in payment providers. opw-6013978 Forward-Port-Of: odoo/odoo#265831
This update speeds up the rendering of stock barcode reports, particularly when dealing with large tables like Accounting reports. By simplifying the CSS rules, the system now recalculates styles more quickly, leading to a smoother user experience during actions like scrolling and resizing.
Original PR description
Avoid using `:has` selector with using a class on body to replace the has behavior. This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. Forward-Port-Of: odoo/enterprise#118362
This update fixes a potential issue during Odoo deployments by logging missing module dependencies. Previously, deployment problems could be difficult to diagnose. Now, a warning is displayed, making it easier to identify and resolve any missing dependencies, streamlining the deployment process.
Original PR description
Log the issue as a warning, and add the missing module dependencies. This should ease managing such deployment issue. Forward-Port-Of: odoo/odoo#266030
This update fixes an issue where the field selector popover was hidden behind the field creation popover in the Email Marketing module. The fix removes an unnecessary offset setting, ensuring the field selector appears correctly and allows users to easily add dynamic fields. This improves the overall user experience.
Original PR description
Problem: In Email Marketing, the field selector popover is displayed behind the field creation popover. Cause: `useOverlayServiceOffset` offsets all `MassMailingIframe` overlay sequences by `+1000` (default sequence `50` becomes `1050`). The field selector popover was using the default sequence, causing it to appear below the main popover. Solution: remove the `useOverlayServiceOffset` hook as it is not needed anymore. Steps to reproduce: - Create a new Email Marketing record. - Try to add a dynamic field. - Open the field selector. - Observe that the selector popover appears behind the main popover, making field selection difficult. opw-6203734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263493
This update fixes an error that occurred when users reviewed eMPF contribution reports. Specifically, the system would fail if an employee wasn't assigned to a contribution line. The fix now prompts the user to assign an employee, ensuring reports can be accurately reviewed.
Original PR description
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. -…
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`. - Create a record by setting the `Scheme` and adding a `contribution line`. - Ensure that the employee and payslip fields are empty in the contribution line. - Click on `Validate`, then click on the `error icon` on the report line. `ValueError: Expected singleton: hr.version()` This error occurs when the user manually adds a line and checks the errors on it.. The system attempts to open the employee record from the version [1], but the version is not set [2] on the line because there is no employee. And it raise the error [3]. This commit ensures that when checking errors, if the version is not set on the line, a UserError is raised, prompting the user to set the employee on the line. It also corrects a typo in the status message. [1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219 [2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156 [3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611 Forward-Port-Of: odoo/enterprise#116607
This update fixes an issue where extra prices on combo products weren't correctly converted to the sale order's currency, leading to inaccurate totals. The change ensures that combo product extra prices are now properly converted, resulting in correct pricing calculations for sales orders in different currencies. This improves the accuracy of sales quoting and invoicing.
Original PR description
The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency Steps to reproduce: 1. Install Sales 2. Go to Invoicing…
The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency Steps to reproduce: 1. Install Sales 2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN 3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN 4. Go to Sales > Products and create a new combo product "test" 5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$ 6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001) 7. Change the pricelist to MXN and update prices 8. The total is ~MX$10,018 (it should be ~MX$186,682) Issue: The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted Solution: Convert the extra price of the combo product to the sale order's pricelist currency opw-6192935 Forward-Port-Of: odoo/odoo#266172 Forward-Port-Of: odoo/odoo#265008
This update resolves an issue where timesheet data wasn't consistently synchronized between Odoo tabs. The fix ensures that changes made in one tab's timesheet are accurately reflected in all other tabs, improving data accuracy and user experience. This prevents discrepancies in timesheet records.
Original PR description
This PR reworks the implementation of https://github.com/odoo/enterprise/pull/116007 Task-6180394 Forward-Port-Of: odoo/enterprise#117914
20 changes
Resolved issues and error corrections
This update replaces instances of 'VAT' with 'Tax ID' across key Odoo modules. This change ensures greater clarity and understanding for users worldwide, particularly in regions where 'VAT' is not commonly used, leading to more accurate reporting and data management.
Original PR description
Similar changes were made before but were incomplete [1]. In the US and many other countries the term VAT is not understood. Use the universally understood Tax ID instead. [1] https://github.com/odoo/odoo/pull/239362 task-6231891
This update replaces the term 'VAT' with 'Tax ID' across Odoo Enterprise, ensuring clarity and accuracy for users worldwide. This change addresses a previous incomplete effort to align with international tax reporting standards, particularly in the US where 'VAT' is not commonly understood. It improves the user experience and data integrity for international clients.
Original PR description
Similar changes were made before but were incomplete [1]. In the US and many other countries the term VAT is not understood. Use the universally understood Tax ID instead. [1] https://github.com/odoo/odoo/pull/239362 task-6231891
This update resolves a problem preventing the correct loading of icon assets (like .woff2 files). The fix ensures consistent handling of asset versions, preventing errors and improving the display of icons on the website. This improves the user experience by ensuring all icons are correctly rendered.
Original PR description
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to…
Currently, an exception is raised while loading icon content assets such as `.woff` or `.woff2`, due to a mismatch between the requested asset version and the latest available version. Steps to produce: - Install website - Open page `/web/assets/1/6a783c3/web.odoo_ui_icons.min.woff2` Error: `UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value` This issue occurs because the code at [1] compares `binary.extension` with `asset_type`, causing the condition to fail because `binary.extension` contains values such as `woff` or `woff2`, while `asset_type` is set to `'binary'`. The root cause is that `asset_type` with value `'binary'` is being passed as a parameter to the `bundle.get_link` method (see [2]). The `asset_type` value comes from the `_parse_bundle_name` method (see [3]), where it is set to `'binary'` whenever the file extension belongs to `BINARY_EXTENSIONS`, such as `woff` or `woff2` (see [4]). This commit fixes the inconsistency between `bundle.get_version()` and `bundle.get_link()` when `binary` is `True`. Currently, `bundle.get_version()` used `extension if binary else asset_type`, while `bundle.get_link()` always received `asset_type`. This could lead to an incorrect redirect when handling binary assets. The fix normalizes the value by updating `asset_type` beforehand and reusing it consistently in both `bundle.get_version()` and `bundle.get_link()`. This also improves readability by removing the inline conditional expression. [1]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/assetsbundle.py#L166 [2]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/addons/web/controllers/binary.py#L146 [3]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/ir_asset.py#L93-L94 [4]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/tools/constants.py#L6-L7 Sentry-7441025709 Forward-Port-Of: odoo/odoo#263506
This update resolves an issue where creating a new bank account with a blank or empty proxy value (CPF/CNPJ or Random Key) would cause an error. The fix ensures that the system correctly handles these cases, preventing the creation process from failing and improving data integrity. This ensures users can consistently create bank accounts within the BR module.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266243 Forward-Port-Of: odoo/odoo#264995
This update fixes an issue where the Table of Contents in the HTML editor wouldn't update after editing headings. Specifically, deleting a heading caused the ToC to stop refreshing. The fix ensures the ToC always updates correctly, regardless of edits made to the content.
Original PR description
Steps to Reproduce : - Go to To-Do → Create New and add a Table of Content block - Type text → in new line create /h1 → it appears in ToC - Place cursor before /h1 and press Backspace → it merges with paragraph Description of the issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 Forward-Port-Of: odoo/odoo#264161 Forward-Port-Of: odoo/odoo#261675
This update resolves a bug in the HTML Editor where resizing the table would cause a crash when a table was deleted. The fix restricts resizing to the primary mouse button and prevents the resize logic from running when there's no valid target, ensuring a smoother and more stable user experience.
Original PR description
#### Description of the issue this PR addresses: - Table resize listeners are not cleaned when the table is removed while resizing - Next mousemove runs resize logic with a null target and throws traceback #### Desired behavior after PR is merged: - Restrict resize start to primary mouse button only - Prevent resize logic execution on null targets #### Steps to reproduce: - Open the todo app - Insert a table and select whole table - Move cursor on a table cell border to see resize cursor - Right click and choose Cut from browser context menu - Move the mouse again - Resize logic crashes with null target traceback task-6212279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266274 Forward-Port-Of: odoo/odoo#264065
This update resolves an error that occurred when users checked the details of eMPF contribution reports. The fix ensures that the system prompts users to correctly identify the employee before generating the report, preventing a technical error. This improves report accuracy and usability.
Original PR description
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. -…
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`. - Create a record by setting the `Scheme` and adding a `contribution line`. - Ensure that the employee and payslip fields are empty in the contribution line. - Click on `Validate`, then click on the `error icon` on the report line. `ValueError: Expected singleton: hr.version()` This error occurs when the user manually adds a line and checks the errors on it.. The system attempts to open the employee record from the version [1], but the version is not set [2] on the line because there is no employee. And it raise the error [3]. This commit ensures that when checking errors, if the version is not set on the line, a UserError is raised, prompting the user to set the employee on the line. It also corrects a typo in the status message. [1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219 [2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156 [3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611 Forward-Port-Of: odoo/enterprise#116607
This update fixes an issue where the template name wasn't correctly displayed after selecting a template using the 'Search More' feature in the employee form. The fix ensures that the correct template label is shown, improving the user experience when loading templates. This prevents confusion and ensures accurate template selection.
Original PR description
Version: - saas-19.1 Steps to reproduce: - Open an employee form. - Click "Load a Template". - Use "Search More" and select a template. Issue: - The selected template label is displayed as "Unnamed" after selecting a template from the search view. Cause: - When selecting a record through "Search More", the returned value only contains the record `id` and does not include `display_name`. As a result, the many2one field cannot render the correct label and falls back to "Unnamed". Fix: - Perform an ORM read to fetch the missing `display_name` using the selected record id, then update `selectedTemplate` with the complete value so the correct template name is displayed. Task-6186635 Forward-Port-Of: odoo/odoo#264556
A rare error causing tracebacks when hovering shape options in website snippets was fixed. The issue stemmed from missing slashes in image source URLs, which prevented a key function from correctly processing the images. This update restores the necessary slashes, ensuring stable operation and preventing these tracebacks.
Original PR description
**Description of the problem** A traceback is generated when hovering shape options in the snippets `s_cta_mobile` and `s_cta_mockups`. **How to reproduce** Drop `s_cta_mockups` -> click one of the two images -> open the shape selector -> hover a shape -> Traceback **Why the problem happens** The "source" attribute of `img` elements in the affected snippets is missing a trailing slash. After PR [1], the regular expression in `loadImageInfo` (html_editor/static/src/utils/image_processing.js) does not match anymore the source, thus the variable that should contain the source string remains empty and a traceback is generated. **Fix** All missing trailing slashes are restored. [1]: https://github.com/odoo/odoo/pull/151858 task-6103616
This update fixes a performance issue that slowed down rendering in Odoo's large reports, particularly when navigating tables like Accounting Balances Sheets. By simplifying the CSS rules, the system now recalculates styles faster, leading to a smoother user experience.
Original PR description
Avoid using `:has` selector with using a class on body to replace the has behavior. This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. Forward-Port-Of: odoo/enterprise#118362
This update ensures that account reconciliation displays accurately after a reconciliation record is removed. Previously, leftover data caused the system to incorrectly show reconciled accounts, even when the reconciliation was no longer active. This fix cleans up the data and corrects the display in the user interface.
Original PR description
### Description `account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default…
### Description
`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.
This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.
### Steps to reproduce
A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:
```python
company = env.ref('base.main_company') # USD company
partner = env['res.partner'].create({'name': 'demo'})
# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
{'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
{'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])
inv = env['account.move'].create({
'move_type': 'out_invoice', 'partner_id': partner.id,
'currency_id': env.ref('base.EUR').id,
'invoice_date': '2026-01-15', 'date': '2026-01-15',
'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()
env['account.payment.register'].with_context(
active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()
recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)
full.unlink() # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False # FAILS without this PR
assert not recv.full_reconcile_id
```
Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.
### Diagnostic query
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
])
```
Returns lines in the orphan state on any database.
### Impact
Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.
### Tests
`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`
### Linked
* Bug report: closes #264790
The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
]).write({'matching_number': False})
env['account.full.reconcile'].search([
('reconciled_line_ids', '=', False),
('partial_reconcile_ids', '=', False),
]).unlink()
```
Forward-Port-Of: odoo/odoo#264805This update ensures that button text colors within the HTML builder align with the overall button styles, creating a more visually consistent and professional design. Previously, the text colors were noticeably different, leading to a less polished user experience. This change improves the builder's usability and aesthetic appeal.
Original PR description
In the html builder, we use strong, neon colors especially for the `btn-success` and `btn-danger`. However, the tint for `text-succes` / `text-danger` was duller, with a bad contrast against the background. This commit simply uses the same color, within builder buttons, for the text classes accent colors as for the btn classes. Forward-Port-Of: odoo/odoo#262277
This update fixes an issue where extra prices on combo products weren't correctly converted to the sale order's currency, leading to inaccurate totals. The change ensures that extra prices are properly converted, resulting in accurate pricing calculations for combo products in different currencies. This improves the reliability of sales order pricing.
Original PR description
The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency Steps to reproduce: 1. Install Sales 2. Go to Invoicing…
The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency Steps to reproduce: 1. Install Sales 2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN 3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN 4. Go to Sales > Products and create a new combo product "test" 5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$ 6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001) 7. Change the pricelist to MXN and update prices 8. The total is ~MX$10,018 (it should be ~MX$186,682) Issue: The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted Solution: Convert the extra price of the combo product to the sale order's pricelist currency opw-6192935 Forward-Port-Of: odoo/odoo#266172 Forward-Port-Of: odoo/odoo#265008
This update fixes a technical error that prevented Odoo from correctly handling email server settings. Previously, missing or invalid configurations would cause errors, now records without email settings are handled smoothly, ensuring reliable email functionality.
Original PR description
Description of the issue/feature this PR addresses: The compute method for `smtp_authentication_info` did not properly handle cases where no `smtp_authentication` value was set. Current behavior before PR: * When `smtp_authentication` was empty or had an unsupported value, `smtp_authentication_info` was never assigned. * This caused the compute method to fail with: `ValueError: Compute method failed to assign ir.mail_server(...).smtp_authentication_info` * As a result, reading or displaying the record could raise an exception. Desired behavior after PR is merged: * The fallback branch explicitly resets `smtp_authentication_info`. * `smtp_authentication_info` is always assigned during computation. * Records without an authentication method no longer raise compute errors and are handled correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266411
This update ensures Knowledge articles always load correctly when printed, regardless of the printing method. Previously, printing through various channels could cause blank pages. Now, CSS rules have been adjusted to prevent unintended styling issues in other Odoo modules, improving the overall printing experience.
Original PR description
Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms…
Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243). To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically. However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge. To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`). This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16. Task-5999878 Forward-Port-Of: odoo/enterprise#109379
This update corrects a restriction in the Recruitment app where Interviewer users could view talent pools but lacked the ability to manage applicants or create new pools. The fix addresses a security rule preventing access to applicants within pools, aligning with the intended role limitations.
Original PR description
## Issue In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the…
## Issue
In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the applicants within the pools, and cannot create new pools either.
## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) with demo data
2. Set Marc Demo's *Recruitment* role to *Interviewer*
3. As Marc Demo, navigate to Recruitment > Applications > By Talent Pools
4. **We can see the existing pools, but they all appear empty ("0 Talents"), and we cannot add talents to a pool, nor create new pools.**
## Cause
Interviewer do not see any applicants in the talent pools because of the following rule:
https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/hr_recruitment/security/hr_recruitment_security.xml#L48-L60
In fact, applicants in talent pools do not have a job_id set:
```sql
190=# SELECT a.partner_name, a.job_id FROM hr_applicant a
190-# JOIN hr_applicant_hr_talent_pool_rel tpr
190-# ON (tpr.hr_applicant_id=a.id);
partner_name | job_id
---------------+--------
Cameron Ellis |
Ethan Carter |
Noah Bennett |
Test Talent |
(4 rows)
```
This leads to no applicants being shown to the interviewers in the talent pools.
## Justification
Interviewers by default only have access to applications who they are interviewer for, it is not intended for them to see entire pools of potential candidates. Letting interviewers access the talent pools view is counter-intuitive, as they have nothing they can do from there.
opw-6187187
Forward-Port-Of: odoo/odoo#265812This update enables payment providers to be duplicated when a branch company is created, aligning with how journals are currently handled in branches. Previously, this was restricted due to accounting preferences, but now it's a more practical approach for branch operations. This simplifies payment setup for businesses with multiple locations.
Original PR description
This PR will allow payment providers to be duplicated into branch companies when a branch company is created. Previously this was prevented because in accounting it's preferred not to use journals in branches. However, there it is still possible to setup a journal in branches. So it makes sense to allow it also in payment providers. opw-6013978 Forward-Port-Of: odoo/odoo#265831
This update optimizes the process of exporting large datasets in Odoo, addressing potential memory issues that could cause slowdowns. By batching export calls and invalidating recordsets, the system now handles larger exports more efficiently, reducing memory usage and improving export speeds. This results in faster data exports for users.
Original PR description
When exporting a number N of records as XLSX or CSV file, we call the export_data() method for the N records at the same time. This method prefetches the selected fields for all the records which can lead to memory limit errors when N is too large. We propose to batch this call and invalidate the recordsets between batches. Benchmarks ----------- Execution time: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 3.82 s | 3.94 s | | 228 116 | 18.71 s | 19.36 s | | 394 381 | 31.02 s | 32.67 s | Memory usage: | No records | Before PR | After PR | |------------|-----------|----------| | 70 260 | 316.0 MB | 273.5 MB | | 228 116 | 796.9 MB | 620.8 MB | | 394 381 | 1.3 GB | 947.7 MB | opw-5881026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266078 Forward-Port-Of: odoo/odoo#257333
This update fixes a potential issue during Odoo deployments by logging missing module dependencies as warnings. This provides clearer alerts for administrators, making it easier to identify and resolve deployment problems. Ultimately, this improves the reliability and manageability of Odoo installations.
Original PR description
Log the issue as a warning, and add the missing module dependencies. This should ease managing such deployment issue. Forward-Port-Of: odoo/odoo#266030
This update fixes a bug that prevented accurate IT tax closing validation, particularly when dealing with quarterly VAT reporting. The changes ensure correct handling of year-end gaps and utilize debit/credit columns in VAT reports, preventing errors and improving the reliability of tax closing processes.
Original PR description
Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080 Forward-Port-Of: odoo/enterprise#117428
8 changes
Resolved issues and error corrections
This update resolves an error that occurred when creating bank accounts using the 'l10n_br' module. Specifically, a falsy value entered for the proxy type (CPF/CNPJ or Random Key) caused a validation error. This fix ensures the module functions correctly when creating bank accounts, preventing data entry issues.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266243 Forward-Port-Of: odoo/odoo#264995
This update corrects a bug in the stock account configuration process. Previously, new stock accounts were created with missing data, leading to incomplete records. This fix ensures updates only apply to existing accounts, guaranteeing accurate and fully populated stock account information.
Original PR description
In the post-init stock configuration we update the chart accounts to add stock-related fields using `_load_data`. The values provided by `_get_stock_account_account` only contain partial data meant…
In the post-init stock configuration we update the chart accounts to add stock-related fields using `_load_data`. The values provided by `_get_stock_account_account` only contain partial data meant to enrich accounts created by the chart template.
The update should only be performed on accounts that already exist. Otherwise, the load creates new account records with most fields left null (e.g. account_type), which is not the intention here.
This fix filters the updates to existing accounts only, so the step only enriches accounts created by the chart template and avoids creating incomplete account records.
steps to reproduce:
- Install account app in a odoo 19 db
- Delete account 'stock valuation'
- Install `stock_account` module
```py
File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 13, in _post_init_hook
_configure_stock_account_company_data(env)
File "/home/odoo/src/odoo/19.0/addons/stock_account/__init__.py", line 79, in _configure_stock_account_company_data
ChartTemplate._load_data({
File "/tmp/tmplqo7rmpu/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5194, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
# [...]
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "account_type" of relation "account_account" violates not-null constraint
DETAIL: Failing row contains (2315, null, 1, 1, null, null, null, t, f, f, 2026-02-17 05:53:58.84587, 2026-02-17 05:53:58.84587, no, f, null, null, null
```
opw-5913248
upg-3879881
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249211This update resolves an error that occurred when users reviewed eMPF contribution reports. Specifically, the system was attempting to access employee information without it being properly set, leading to a system error. The fix ensures a user-friendly error message is displayed, prompting the user to correctly populate the employee details before reviewing the report.
Original PR description
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. -…
Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`. - Create a record by setting the `Scheme` and adding a `contribution line`. - Ensure that the employee and payslip fields are empty in the contribution line. - Click on `Validate`, then click on the `error icon` on the report line. `ValueError: Expected singleton: hr.version()` This error occurs when the user manually adds a line and checks the errors on it.. The system attempts to open the employee record from the version [1], but the version is not set [2] on the line because there is no employee. And it raise the error [3]. This commit ensures that when checking errors, if the version is not set on the line, a UserError is raised, prompting the user to set the employee on the line. It also corrects a typo in the status message. [1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219 [2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156 [3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611 Forward-Port-Of: odoo/enterprise#116607
This update fixes a bug that prevented accurate IT tax closing validation, particularly when dealing with quarterly VAT reporting in Italy. The changes ensure correct handling of year-end gaps and utilize debit/credit columns in reports, preventing errors and improving the reliability of tax calculations.
Original PR description
Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080 Forward-Port-Of: odoo/enterprise#117428
This update fixes a performance issue in the Stock Barcode module, specifically related to how the user interface is rendered. By simplifying the CSS rules, the system now recalculates styles faster, leading to quicker response times when navigating large reports or interacting with the application.
Original PR description
Avoid using `:has` selector with using a class on body to replace the has behavior. This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance. Forward-Port-Of: odoo/enterprise#118362
This update resolves an issue preventing the attendance system from correctly filtering employees based on their country code. The fix grants necessary access rights to read the country code, ensuring accurate attendance reporting and payroll calculations. This improves the reliability of the HR attendance module.
Original PR description
/hr_attendance:TestAttendanceManager.test_attendance_manager_rights uses write function defined in l10n_sa_hr_payroll_attendance which in some cases requires to read the country_code of an employee to filter. Access rights on employees blocked it from reading country_code. Added sudo on employee for reading and filtering on country_code. task-6226413
This update resolves an issue where account reconciliation lines remained incorrectly marked as reconciled after being deleted. The fix ensures that matching numbers are properly cleared from related account move lines, preventing misleading UI displays and maintaining data integrity. This improves the accuracy of financial reporting.
Original PR description
### Description `account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default…
### Description
`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.
This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.
### Steps to reproduce
A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:
```python
company = env.ref('base.main_company') # USD company
partner = env['res.partner'].create({'name': 'demo'})
# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
{'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
{'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])
inv = env['account.move'].create({
'move_type': 'out_invoice', 'partner_id': partner.id,
'currency_id': env.ref('base.EUR').id,
'invoice_date': '2026-01-15', 'date': '2026-01-15',
'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()
env['account.payment.register'].with_context(
active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()
recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)
full.unlink() # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False # FAILS without this PR
assert not recv.full_reconcile_id
```
Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.
### Diagnostic query
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
])
```
Returns lines in the orphan state on any database.
### Impact
Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.
### Tests
`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`
### Linked
* Bug report: closes #264790
The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:
```python
env['account.move.line'].search([
('matching_number', '!=', False),
('matching_number', 'not like', 'P%'),
('matching_number', 'not like', 'I%'),
('full_reconcile_id', '=', False),
]).write({'matching_number': False})
env['account.full.reconcile'].search([
('reconciled_line_ids', '=', False),
('partial_reconcile_ids', '=', False),
]).unlink()
```
Forward-Port-Of: odoo/odoo#264805This update ensures a more visually appealing and accessible HTML Builder by standardizing accent colors across buttons and text elements. Previously, the text colors lacked sufficient contrast, now they align with the button styles for better readability and a more polished design.
Original PR description
In the html builder, we use strong, neon colors especially for the `btn-success` and `btn-danger`. However, the tint for `text-succes` / `text-danger` was duller, with a bad contrast against the background. This commit simply uses the same color, within builder buttons, for the text classes accent colors as for the btn classes. Forward-Port-Of: odoo/odoo#262277
4 changes
Resolved issues and error corrections
This pull request updates the core spreadsheet component within Odoo. It includes fixes related to data export formulas, handling of spreadsheet ranges, and improvements to pivot table functionality. Additionally, it incorporates new skills related to Claude AI testing and review.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fc3445633c [REL] 18.3.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fc3445633c [REL] 18.3.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e174b48022 [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405) https://github.com/odoo/o-spreadsheet/commit/ae0a2d6196 [FIX] range: correctly handle unbounded ranges on row/col changes [Task: 6167358](https://www.odoo.com/odoo/2328/tasks/6167358) https://github.com/odoo/o-spreadsheet/commit/141b73bf40 [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/7efcbdf6ed [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/b98b4452aa [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095) https://github.com/odoo/o-spreadsheet/commit/3a2d803b5d [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b019a59681 [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a problem where double-clicking images in the Media Dialog triggered multiple actions, causing performance issues. A simple flag has been added to ensure that the media flow is only processed once during a single click, improving the user experience and stability.
Original PR description
Before this commit: When double-clicking an image in the Media Dialog, the onClickAttachment method was executed twice, causing the media flow to be processed multiple times. After this commit: The issue is fixed using a boolean flag: isProcessingClick. Initially, the flag is set to false. When the first click starts, it is updated to true. If another click occurs during the same flow (e.g during a double click), isProcessingClick is already true, so the function immediately returns and prevents the action from being executed multiple times. task-6033320 Forward-Port-Of: odoo/odoo#254790
This update resolves an issue where delivery orders for serial-tracked products could be completed without recording the necessary serial numbers. The fix ensures that when a user removes all serial numbers from a move line during a delivery order creation, the system prevents the order from being validated as 'done' without a serial number recorded. This maintains data accuracy and compliance.
Original PR description
Writing both `quantity` and `lot_ids` on a tracked move in the same form save leaves `move.quantity` stored at the user value while `_set_lot_ids` unlinks the remaining move line; the picking can then be validated to 'done' with no serial recorded. Force `_compute_quantity` at the end of `_set_lot_ids` so the stored value stays in sync with the move lines. Steps to reproduce: - Serial-tracked product, 6 in stock - Create a delivery order for 6 units of that product - In the delivery form, on the move row: type "1" in Quantity and remove all 6 lots from the Serial Numbers widget. - Save, Validate Before: picking goes to Done with quantity=1 and no serial. After: clear UserError, quantity stays in sync with mls. opw-6192841 Forward-Port-Of: odoo/odoo#266394
This update fixes an issue where quality alerts weren't being created when incoming emails were processed without a company assigned. The fix ensures that a default company ID is used, preventing errors and guaranteeing that all email-based quality alerts are correctly recorded. This improves the reliability of our quality tracking system.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#109947
1 change
Resolved issues and error corrections
This update fixes an issue where Quality alerts weren't being created when incoming emails didn't include company details. The fix ensures that a default company ID is assigned, preventing errors and allowing all inbound emails to generate quality alert records. This improves the reliability of the Quality module.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#109947
29 changes
Enhancements to existing features
This update simplifies how contract availability is displayed in the Gantt view, making it easier to visualize resource scheduling. The changes include refactoring test cases and adding new functionality to integrate contract unavailabilities directly into the Gantt chart. This improves the overall planning process and resource management.
Original PR description
<h3><b>[REF] planning: refactor changes from planning_contract</b></h3> Contract unavailabilities have been simplified using gantt unavailabilities. The hoot test cases have been refactored as we have unified the mock models. Moved a test case to community. --- <h3><b>[IMP] project_enterprise_hr: add contract based graying in gantt view</b></h3> Added contract unavailabilities through gantt unavailabilities. Added some hoot test cases. task-3885152
This update refactors the existing Hong Kong AutoPay module to create a more flexible and extensible system. The changes broaden support beyond just HSBC, allowing for easier integration with other banks in Hong Kong and future expansion. This improves the overall automation of payment processing for Hong Kong businesses.
Original PR description
Refactor the hsbcnet module, aiming to: - Transform it into a general 'Hong Kong AutoPay' module, covering more than just HSBC - Re-design the module to be easily extensible for future support of extra banks. task-6007861
This update provides users with the option to view financial changes between periods as either a percentage or a precise monetary amount. Previously, only percentage changes were available, which could be misleading when tracking large financial impacts. This change offers a more direct and accurate representation of the actual financial difference.
Original PR description
Right now the period-comparison filter allows for a % change to be visible as an additional column between two periods. Sometimes, if you are trying to keep track of large figures and want to see the real world financial impact of changes between periods, a percentage can't help. This commit allows for users to decide if they want a **Percentage** comparison (the default that preserves the current behavior) or an absolute **Amount** shown via the comparison filter. As we are dealing with currency, the amount column will show the real v1 - v2 difference displayed as a monetary field and works off the source column to properly support multi-currency reports. In addition, it takes into account the rounding unit for better display views. The column header switches between "Change (%)" and "Change (<currency_symbol>)". task-6116196
This update enhances the usability of the Manufacturing, Quality, and Shop Floor apps by refining the Gantt view scales and improving the Quality Point form. Specifically, the Quality Check form now includes access to worksheets and attachments, streamlining the inspection process and aligning the Shop Floor interface for a more consistent user experience.
Original PR description
This PR improves the user experience in the Manufacturing, Quality and Shop Floor app and adds the worksheet to the quality check form. Task-id: 6164381
This update ensures that new employees in Belgian companies automatically receive their payslips in the local language (French, Dutch, or German) if the company's environment uses one of these languages. This improves the user experience and compliance with Belgian regulations, making payslips easier to understand for employees.
Original PR description
After this commit, when a new employee is created in a Belgian company, their payslip's language defaults to the environment's language if this language is one of the Belgian national languages i.e. French, Dutch or German. A test has been added to verify the correctness of the behaviour. task-6234693
This update introduces a new system for managing salary rules within Odoo's payroll, allowing for more flexible and granular control over employee compensation. Specifically, it enables the definition of multiple 'structures' associated with salary rules, improving the handling of diverse payroll scenarios and supporting more complex business requirements. This change enhances the accuracy and adaptability of payroll calculations.
Resolved issues and error corrections
This update corrects a display issue where VoIP call durations were incorrectly shown in hours. The change converts the duration to store in seconds and displays it in a user-friendly format, eliminating potential rounding errors and simplifying the display. This ensures accurate call duration information for users.
Original PR description
Currently, duration on voip.call is stored in hours. But when we show the duration, we always need to show the seconds. This can cause several potential issues like rounding errors, unnecessary conversions. In this commit, we convert the duration field to store in seconds, also we convert type from float to integer. Task-[6128312](https://www.odoo.com/odoo/5778/tasks/6128312) COMPR: https://github.com/odoo/odoo/pull/264031 UPGPR: https://github.com/odoo/upgrade/pull/10199
This update fixes a technical issue related to the way invoice PDF legends are configured in Odoo. The field was incorrectly set to be company-dependent, which caused unexpected behavior. This change reverts the field to a standard computed value, ensuring consistent invoice generation.
Original PR description
The field `l10n_ar_invoice_pdf_legend` of res.company being company dependent was a mistake. We should change it back to a normal computed field. commit it was added: odoo/enterprise@c72681b5e1036f53de71ac422282127a95a2adc9
This update resolves a problem where WebP image formats in the demo data were causing errors when generating PDFs. The team has switched to using standard JPEG images, ensuring consistent and reliable PDF output for the sales demo.
Original PR description
WebP images used in the demo data caused issues in PDFs. Use JPEG instead.
This update resolves a minor visual issue in the Odoo Enterprise view editor. The XML mode within the editor previously lacked the correct background color, which has now been corrected. This ensures a consistent and professional user experience when designing views.
Original PR description
Following https://github.com/odoo/enterprise/issues/103707 which introduced a little bug, causing the xml editor of the view editor to not have the correct background color after this commit, the background color is corrects
This update simplifies the process of creating intercompany sales and purchase documents. The previous system unnecessarily generated document names, which has now been removed. This change improves the system's flexibility and efficiency.
Original PR description
The intercompany sale and purchase document creation explicitly calls next_by_code to generate document names, even though sequence assignment is already handled in create(). This explicit sequence generation is redundant and reduces the extensibility of the sequence flow. Remove the redundant next_by_code calls and rely on the standard create() flow for sequence assignment.
This update fixes a confusing naming issue within the Tax Returns page of Odoo Enterprise. The breadcrumbs now display correctly, ensuring a smoother user experience when navigating between tax return records. This change improves clarity and usability for users managing tax returns.
Original PR description
The "Tax Returns" page/breadcrumbs are currently called "Tax Return". This creates a confusing naming scheme with the breadcrumbs if you click into a new page from within an individual tax return after opening it from the Tax Returns page. Without the fix, the breadcrumbs would appear as "Tax Return/Tax Return" After the fix, they will appear as "Tax Returns/Tax Return". The page name has also been changed to "Tax Returns" with this fix.
This update simplifies the Gantt chart by removing a previously unnecessary feature. Previously, users couldn't easily select all records or expand all groups. Now that both options are available, this redundant element has been removed, streamlining the user experience.
Original PR description
Following the PR #179887, we introduced the possibility to remove the default group by. This was useful because: * The select all only selected the visible records * There was no possibility to expand all groups But now we can do both. This commit thus removes the default_group_by facet from all views and adapts the unit tests relying on it. community PR: https://github.com/odoo/odoo/pull/265574 task-6218432
This update resolves an issue where the 'Off-Cycle' button was unexpectedly displayed during new pay run batch creation. The fix ensures this button is hidden, streamlining the payroll process for users and preventing potential confusion. This improves the user experience and data accuracy.
Original PR description
The "Off-Cycle" button appears when selecting employees for a new pay run batch. Fixed by passing `hide_off_cycle_btn: true` inside the JS file context and evaluating it inside the XML button's `invisible` attribute. Task: 6240692
This update ensures that currency selection is now properly available when generating financial reports within Odoo Enterprise. Previously, this functionality was missing, leading to potential inaccuracies in reporting. This change improves the reliability and accuracy of financial data for users.
Original PR description
https://github.com/odoo/odoo/pull/262209
This update removes unnecessary scrollbars from the employee and manager feedback frames, resulting in a cleaner and more user-friendly experience on desktop views. Previously, the layout forced double scrollbars when content exceeded the screen size. Now, only the main page scrollbar is visible, improving readability and usability.
Original PR description
Prior to this commit, the employee and manager feedback frames were bound to the layout using 'vh-100' and 'scrollable-section'. This forced aa double-scrollbar layout on desktop views when text exceeded the screen size. This commit removes these layout classes from the XML view, allowing the feedback frames to expand vertically with their content so that only the main page scrollbar remains. Task: 6237029
This update fixes a limitation where basic users couldn't create new spreadsheets using the 'New' > 'Spreadsheet' option. By granting all users access to templates, this change enables basic users to create and manage spreadsheets, improving their workflow and functionality.
Original PR description
Basic document user can already create spreadsheet either by using the "New" button or uploading a document. The "New" > "Spreadsheet" button from document doesn't work because we don't have access to template. This task give access to their template to all users. It also allows basic user to create template as they will be able to create spreadsheets. Task: 6022218
This update ensures that payment notifications, receipts, and emails are sent to the correct contact – the invoice contact – when a partner has an invoice associated with them. This corrects a previous issue where payments were incorrectly sent to the commercial partner, maintaining accurate accounting records and reporting.
Original PR description
**Context:** Before this commit `account.payment.partner_id` was restricted (by domain) to commercial partners. When a partner has an invoice contact child (`type='invoice'`), checks, receipts and outgoing emails end up addressed to the parent partner instead of the intended invoicing contact. Accounting entries must still be linked to the commercial partner to preserve reporting & reconciliation integrity. **Solution:** The invoice model (`account.move`) already solves the same problem: `partner_id` stores the communication contact, `commercial_partner_id` is the stored compute used for accounting. This commit mirrors that architecture on `account.payment`. task-6123823
This update prevents errors during inventory counts when a company doesn't have a default warehouse. Now, users are automatically redirected to create a warehouse if one isn't already set up, ensuring a smoother inventory process. This improves usability and avoids disruptions.
Original PR description
In this [commit](https://github.com/odoo/odoo/commit/100cab4b1093ead8b35ec73c7fd41d90647cabbc), we introduced a flow where a warehouse is automatically created only for the first company. For subsequent companies, no warehouse is created by default. When no warehouse exists, adding a product during an inventory count in the barcode module raises a traceback because it tries to access a non-existent warehouse location. This improvement handles the case by giving the user an option to redirect to the warehouse view and create a new one. Community PR: https://github.com/odoo/odoo/pull/258129 TaskId-6098303
This update adjusts the stock management test to align with recent changes in Odoo (odoo/odoo#250422) that introduced new data keys for the product catalog. This ensures the test accurately reflects the current functionality and avoids potential issues related to unit testing.
Original PR description
This commit adapts for the changes in odoo/odoo#250422, which adds new keys to the data dict used by product catalog. Task-5917766
This update removes a default selection toggle within the salary rule configuration, streamlining the process for users. The change ensures the first option is automatically selected as the default, aligning with updated system logic. This simplifies configuration and reduces potential user confusion.
Original PR description
[IMP] hr_payroll: remove salary rule selection input default
There was a default toggle in the selection input for determining the input_default_selection.
I removed it and according to the sequence, the first one is selected as default.
task - 6023720This update fixes a technical issue related to the Thailand tax reporting module (l10n_th_reports). It replaces outdated references to tax tags with a more flexible system that connects to report expression records. This ensures accurate and consistent VAT reporting for Thai businesses.
Original PR description
Following the tax tag renaming in l10n_th, replace hardcoded tag name strings with lookups on report expression records. Community PR: https://github.com/odoo/odoo/pull/266327 task-6002110
This update corrects a faulty test within the Odoo payroll system. The previous test was unreliable (flaky) and its steps were incorrect, preventing accurate identification of issues. This fix ensures the tour test functions correctly, improving the stability of the payroll module.
Original PR description
The test is flaky, and the steps are wrong, we are missing the continue steps. task-6238273
This update resolves an issue where Odoo branches were incorrectly inheriting VAT information from their parent companies, leading to manual VAT adjustments. The change now defaults branches to no VAT, ensuring the parent company remains the key provider and simplifies the system for users. Key settings are also restricted to the base group for improved security.
Original PR description
Branches copied the parent's VAT, which made them their own signing entity and forced users to clear the VAT so the branch would reuse the parent's keys. Default branches to no VAT so the parent remains the key provider. Setting a VAT on a branch still exposes the key settings for the rare case separate keys are needed. Also restrict the key settings to base.group_system task_id - 6087168 Forward-Port-Of: odoo/enterprise#117986
This update ensures that canteen costs are accurately calculated when an employee has multiple workdays with the same canteen code on a single payslip. Previously, the system didn't account for this, leading to potential inaccuracies in monthly pay calculations. This fix corrects this issue, ensuring accurate payroll processing.
Original PR description
Before this commit, canteen costs for the monthly pay did not take into account that multiple worked day lines with the same code can be present on the same payslip. no related task Forward-Port-Of: odoo/enterprise#118020
This update fixes an issue preventing users from importing emissions data within the ESG module. The change allows the 'import' action to appear in the COG menu, even with the 'create' attribute disabled, ensuring seamless data import functionality. This improves the usability of the ESG reporting features.
Original PR description
Before this commit, the "import" action of emissions in the ESG module was not visible in the COG menu. It is because the "create" attribute of the list view is disabled, which prevents the menu item from being displayed. With this commit, we override the standard behavior in this particular action, by allowing the import action to show up in the COG menu, even if the "create" attribute is disabled. version-19.1 Forward-Port-Of: odoo/enterprise#118004
This update fixes a warning that appeared during payrun creation, specifically when running multiple payruns or adjusting payroll schedules. The issue stemmed from an error in how the system processed domain settings, which has now been corrected to prevent the warning and ensure stable payrun functionality.
Original PR description
[FIX] hr_payroll: fix payrun warning bug Bug reproduction: When we select Employee Type and all employees and create a payrun. Do this twice at least. Then set your schedule in the dashboard of payroll app. Error will appear. Bug cause: There was ast.literal_eval(action['domain']) part where action refers to action_hr_payslip_run but action['domain'] is False and ast.literal_eval(action['domain']) throws and error Bug solution: I said ast.literal_eval(action['domain'] or '[]'), in case action['domain'] is False, we should return [] domain to prevent throwback. task - 6227118 Forward-Port-Of: odoo/enterprise#117595
Code cleanup and technical improvements
This update adapts the composer date picker within the O-Spreadsheet module to a recent change in how references are handled. The team removed an older reference system and switched to a more efficient signal-based approach. This ensures the date picker continues to function correctly with the latest O-Spreadsheet updates.
Original PR description
In o-spreadsheet, we removed `t-custom-ref` and replaced it with `t-ref` that use signal. This commit adapt the composer date picker to this change.
This update refactors the Australian Payroll API code to improve its efficiency. By using a more streamlined method for data retrieval, the change enhances the speed and reliability of the API, ensuring smoother integration with payroll systems. This results in faster processing times and a more stable experience.
Original PR description
https://github.com/odoo/odoo/pull/264765
4 changes
New functionality added to Odoo
This update introduces a new reporting type specifically for Indonesian tax returns within the Odoo Enterprise system. This addition allows businesses operating in Indonesia to accurately track and report their tax obligations, streamlining compliance processes. It expands Odoo's capabilities to meet the specific requirements of the Indonesian market.
Original PR description
Create new module l10n_id_reports and add return type for Indonesia. task-6239169
Resolved issues and error corrections
This update corrects a technical issue in the GSTR2B report generation, ensuring accurate reporting of non-GST supplies. The change updates a key used to identify these supplies, resolving a potential discrepancy in tax reporting. This ensures compliance and reliable data for tax filings.
Original PR description
Before this commit, the domain of the non-GST supplies report line in GSTR2B used the GSTR section `purchase_nongst`, while the actual section key is `purchase_non_gst_supplies`. This commit fixes the domain by using the correct GSTR section key. task-6239820
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the Kenyan Revenue Authority (KRA) eTIMS system. The fix truncates descriptions to meet the 200-character limit specified by eTIMS, ensuring successful invoice submission and avoiding delays. This prevents potential disruptions to VAT processing.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129 Forward-Port-Of: odoo/enterprise#118152
This update ensures that when a marketing automation email fails and is retried, it only resends to records within the original campaign filter, not the entire mailing template. Previously, clicking 'Retry' sent emails to all records matching the template, causing unintended distribution. This fix maintains accurate targeting and prevents wasted email sends.
Original PR description
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a…
Clicking Retry on a mailing tied to a marketing automation campaign resends the email to records outside the campaign filter instead of only the failed recipients. ### Steps to reproduce 1. Create a marketing automation campaign with a filter. 2. Add an email activity and start the campaign. 3. Force at least one email to fail. 4. Click Retry on the mailing form. The email is sent to every record matching the mailing template, not just the failed ones. ### Cause When an activity runs, it computes the matching record ids from the campaign filter and calls `action_send_mail(res_ids)` with that explicit list. The Retry button calls `action_retry_failed`, which deletes the failed mails and traces, flips the mailing to `in_queue`, and lets the mass mailing cron resend it. That cron calls `_action_send_mail()` with no ids, so it falls back to the mailing template's own domain, which is unrelated to the campaign filter. ### Fix Override `action_retry_failed` for mailings tied to a marketing activity. Instead of requeuing through the mass mailing cron, reset the failed `marketing.trace` rows back to `scheduled`, cancel their already scheduled children so the next run does not double up, reactivate any participant that was marked `completed`, and trigger the marketing automation cron. That cron runs `execute_on_traces`, which re-applies the campaign filter before sending. Non automation mailings keep the original behavior via `super()`. opw-6010465
7 changes
Resolved issues and error corrections
This update fixes an issue where the calculation of gross total amounts with both line and global discounts was incorrect. The change ensures accurate calculations by reordering the discount application process, resulting in the correct total before taxes and discounts are applied. This improves invoice accuracy and reliability.
Original PR description
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact…
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines. Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10) = 98.889 This does not equal the expected outcome of $100. Expected Behavior: Based on the previous example, the formula for the calculation should be: (raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9 = 100 The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts. Steps to reproduce the issue: - Bug was encountered when implementing a global discount solution for l10n_co_dian. - Create an invoice with a product line and in-line discount and another line for global discount - Setup the base lines for the invoice and attempt the following: - _dispatch_global_discount_lines - _squash_global_discount_lines - _add_and_round_raw_gross_total_excluded_and_discount opw-5412446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug in the Mexican VAT (l10n_mx_edi) module that resulted in incorrect discount and subtotal calculations on invoices with both product and global discounts. The change ensures accurate test coverage and reliable invoice totals for Mexican businesses. This resolves a discrepancy in how discounts were applied.
Original PR description
Purpose: A bug was found in the calculation of the `raw_discount_amount` and `raw_gross_total_excluded` when `_add_and_round_raw_gross_total_excluded_and_discount` is called on an invoice that contains both product line discounts and global discounts. Therefore, the discount and subtotal amounts for the test case testing both line and global discounts need to be corrected to ensure accurate test coverage. opw-5412446
This pull request updates the o_spreadsheet library, which is used for the spreadsheet functionality within Odoo. The changes include bug fixes related to data export formulas and pivot tables, as well as improvements to the library's packaging and build process. These updates ensure the spreadsheet feature continues to function correctly and efficiently.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/50b85ba821 [REL] 18.0.69 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/50b85ba821 [REL] 18.0.69 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bdbbd561b8 [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405) https://github.com/odoo/o-spreadsheet/commit/6fab32ce9c [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/76db3fd593 [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894) https://github.com/odoo/o-spreadsheet/commit/cb7495111b [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095) https://github.com/odoo/o-spreadsheet/commit/6f9561dde5 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9d85891b99 [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/56c4ce1c04 [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/a0763ab621 [REL] 18.0.68 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b9dbc33c4e [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/9ee74660ae [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d0fca1409e [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/06413dab98 [REL] 18.0.67 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/533e5f08da [FIX] package: update package-lock.json [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/090f75ba4d [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2effff1d86 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6a24b125d4 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d86edeb9f7 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where the website editor would revert changes after a failed save attempt, causing frustrating delays and incorrect behavior. The fix ensures the editor remains stable and responsive even when a save operation doesn't complete successfully, improving the user experience.
Original PR description
When a save fails (for example due to a required field), the editor stays open, but some transient editor classes may already have been removed from the DOM.
This leaves the editor in an inconsistent state and can trigger a weird flow while making changes.
For example, as a result, users may see every second keystroke ignored after a failed save.
Steps to reproduce:
- Open a product page in website editor
- Remove the product name
- Click save
- The expected popover is shown ("Operation cannot be completed")
- Type again in the product name field => Every second keystroke is ignored (rollbacked actually).
task-5190459
Forward-Port-Of: odoo/odoo#263568This update corrects a technical issue related to withholding tax (WHT) reporting in the Philippines (l10n_ph). It prevents WHT repartition lines from incorrectly contributing to the periodic VAT closing entry, ensuring accurate tax calculations and reporting. This change improves the reliability of financial data.
Original PR description
Set `use_in_tax_closing` to False on withholding tax (WHT) repartition lines, as they should not contribute to the periodic VAT closing entry. task-6146238
This update resolves an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank file exports, leading to rejections. The fix ensures '&' is preserved in name and address fields, aligning with banking standards and preventing errors.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#115409This update fixes a potential issue where users could inadvertently select inactive Intrastat codes when configuring products. Now, a warning message will appear if a user attempts to select an inactive code, preventing incorrect data entry and ensuring accurate reporting for Intrastat purposes. This improves data integrity and compliance.
Original PR description
Problem: When choosing an intrastat code on a product, all the codes are shown, even the ones that are expired or not yet active. Users can select an intrastat code that is not active. Steps to reproduce: 1. Check the intrastat code list and find a code with a start date in the future or an expiry date in the past 2. Note the code description 3. Open a product form view and try to set/change the intrastat code 4. Search for the code description noted in step 2 5. Note that the code is proposed while it should not be proposed Solution: When an intrastat code is selected, if the code is not active, a warning message is shown to the user. opw-6217915 Forward-Port-Of: odoo/enterprise#117884