Odoo Changelog — 2025-03-26

Wednesday, March 26, 2025

61 changes · saas-18.2

Bug Fixes(7)

Resolved issues and error corrections

[FIX] html_editor: prevent infinite loop in link tools

PR #203295

Coresaas-18.2html_editor

This fixes an issue where rapidly switching between pasted links in the editor could cause the link preview to appear blank. The change prevents the link tools from repeatedly reopening and closing, improving reliability when editing descriptions or other rich text fields.

Original PR description

**Problem**:
Calling `closeLinkTools` on `link.isConnected` sets the selection, which triggers `selectionchange`, leading to `openLinkTools`, which then calls `closeLinkTools`, causing an infinite loop.

**Solution**:
In `openLinkTools`, use `this.overlay.close();` to close the link popover without changing the selection.

**Steps to reproduce**:
1. Create a new task.
2. Select and copy the task's URL.
3. Paste the URL in the description.
4. Press Enter.
5. Paste the URL again.
6. Click quickly between the two URLs.
   - **Issue**: Sometimes, the link preview appears blank.

**opw-4669353**

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#editor#links#link-preview

[FIX] base: traceback server action

PR #203423

Coresaas-18.2base

Creating a new server action and choosing the Webhook type no longer triggers an error before a model is selected. This prevents an avoidable setup interruption and makes configuring automated actions smoother for users.

Original PR description

When you create a new server action and select the type "Webhook", you get a traceback because no model is set yet on the server action.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#server actions#webhook#stability

[FIX] hr_expense: search view use ilike instead of =like

PR #203435

Coresaas-18.2hr_expense

Expense search filters now match partial words automatically, making it easier for users to find the records they need. Users no longer need to know exact terms or add special wildcard characters when searching expenses.

Original PR description

Since the search view are used by final users and they are most of time search on partial words, we don't want to force them to use an exact match or add manually "%" at the beginning and end of their search.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#search#expenses#usability

[FIX] base: cron auto-vacuum race

PR #203304

Coresaas-18.2basecalendar

Scheduled cleanup now avoids competing with active scheduled jobs for the same records. This reduces the chance of background jobs waiting on database locks, improving reliability without changing user-facing workflows.

Original PR description

When a cron is starting, it removes all triggers that are in the past and the autovacuum job on triggers removes all triggers older than a week. When the autovacuum tries to run, there is a high probability that a cron is already running and rows are being deleted/locked.

We change the autovacuum so that it only removes the records for inactive cron jobs because the active ones will already be removed when that job will start.



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#cron#maintenance#reliability

[FIX] hr_appraisal: report state

PR #82170

Enterprisesaas-18.2hr_appraisal

This fix ensures appraisal reports use the correct colors for their current status after status names changed. It helps users quickly read appraisal report states correctly and avoids misleading visual indicators.

Original PR description

ref: <https://runbot.odoo.com/odoo/error/161511>

- fix the `COLORS_BY_STATE` with the new state keys

#appraisals#reports#status

[FIX] sign: post merge ui fixes

PR #79448

Enterprisesaas-18.2sign

This fix ensures signature fields keep their intended alignment when users place them on documents. It helps make prepared signing documents look more consistent and reduces manual adjustment after adding fields.

Original PR description

This commit addresses post merge fixes in the UI after the big rework of the sidebar and UI improvements:
- Fix alignment of the sign items when being dropped, as from now on sign items follow the pre-defined alignment and are not forced to be rendered in the center anymore.

task-4555838

#sign#documents#ui#alignment

[FIX] account_reports_cash_basis: fix duplicate account code

PR #80956

Enterprisesaas-18.2account_reports_cash_basis

This change removes a test setup step that reused an existing account code, preventing duplicate-code conflicts during automated validation. It helps keep accounting report test runs stable without changing day-to-day user functionality.

Original PR description

The Issue:
Prior to this commit, when changing the account code for Outstanding Receipts for the test test_cash_basis_general_ledger_load_more_lines, the code '101403' already exists.

The Fix:
remove the line that force writing the existing account code

runbot-134665

#accounting#cash basis#testing

Other(54)

Miscellaneous changes

[FW][IMP] web: log exports

PR #203530

Coresaas-18.2web

Original PR description

For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the…

For forensics purposes, having a log when users are doing an export is useful.

In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models.

However:
- The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`.
- During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs.

Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing.

A rework of the API of `export_data` is planned in master to solve the above concerns.

Forward-Port-Of: odoo/odoo#203388
Forward-Port-Of: odoo/odoo#202568

**Problem**: Calling `closeLinkTools` on `link.isConnected` sets the selection, which triggers `selectionchange`, leading to `openLinkTools`, which then calls `closeLinkTools`, causing an infinite loop. **Solution**: In `openLinkTools`, use `this.overlay.close();` to close the link popover without changing the selection. **Steps to reproduce**: 1. Create a new task. 2. Select and copy the task's URL. 3. Paste the URL in the description. 4. Press Enter. 5. Paste the URL again. 6. Click quickly between the two URLs. - **Issue**: Sometimes, the link preview appears blank. **opw-4669353** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When you create a new server action and select the type "Webhook", you get a traceback because no model is set yet on the server action. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Since the search view are used by final users and they are most of time search on partial words, we don't want to force them to use an exact match or add manually "%" at the beginning and end of their search. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When a cron is starting, it removes all triggers that are in the past and the autovacuum job on triggers removes all triggers older than a week. When the autovacuum tries to run, there is a high probability that a cron is already running and rows are being deleted/locked. We change the autovacuum so that it only removes the records for inactive cron jobs because the active ones will already be removed when that job will start. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This commit addresses post merge fixes in the UI after the big rework of the sidebar and UI improvements: - Fix alignment of the sign items when being dropped, as from now on sign items follow the pre-defined alignment and are not forced to be rendered in the center anymore. task-4555838

The Issue: Prior to this commit, when changing the account code for Outstanding Receipts for the test test_cash_basis_general_ledger_load_more_lines, the code '101403' already exists. The Fix: remove the line that force writing the existing account code runbot-134665

For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`. - During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs. Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing. A rework of the API of `export_data` is planned in master to solve the above concerns. Forward-Port-Of: odoo/odoo#203388 Forward-Port-Of: odoo/odoo#202568

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move. ### Steps to reproduce: - Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2 - Create a delivery order for 2 units and mark as to do. > The two SN's should be reserved on your delivery. - Go to the barcode app, scan SN1. - Edit edit the SN1 line to set the qty back to 0. - Leave the barcode app and come back to the record. #### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily. ### Cause of the issue: In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked: https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons: 1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0. 2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value. We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process. https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22 Enterprise: https://github.com/odoo/enterprise/pull/80675 opw-4600565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202882 Forward-Port-Of: odoo/odoo#200167

When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is the creation of a new package level. Both of these can be a bit slow when the picking's number of move_lines gets bigger. This can happen for SN tracked products for instance. In a database with 1800 move_lines, each _put_in_pack call takes around 1.5s, which can become cumbersome when customers are using multiple packages. Most of this slowness is coming from two things. The first one is stock.quants synchronization when writing on move.lines. The propose solution in this commit is to skip this synchronization when the only value in the vals dict is `result_package_id`. We can do that because this value is not used in the first quants synchronization of the write method. The second one is a write of `location_dest_id` on the picking's move_ids and move_line_ids in `package_level.create`. Since the package_level.location_dest_id value is coming from the `move_line_ids` value in `_put_in_pack`, this commit adds a context key to skip this write in case we're coming from `picking._put_in_pack` #### speedup In a 17.4 customer database, putting in pack for a picking with 1800 move_lines: 1.5s -> 90ms --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202967 Forward-Port-Of: odoo/odoo#200767

Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products. Steps to reproduce: --- - Install `event_product` application (without demo data). - Delete `Event Registration` from products - Now install `pos_event` module Traceback: --- ``` Exception: Cannot update missing record 'event_product.product_product_event' ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_event/data/event_product_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product"> <field name="available_in_pos">True</field> <field name="pos_categ_ids" eval="[(6, 0, [ref('pos_event.pos_category_event')])]"/> </record> ``` The error occurs because the user deleted the product, and then tried to install the other module. This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks. https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364 sentry-5731062091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199010

Fw-port Transifex translations from major version to non-major versions Also copied changes done in v18 by https://github.com/odoo/enterprise/commit/717db6525383a181ae0d211989824ddd1413712b In Swiss localization: - Re-added in help descriptions that were removed in field overrides since they nicely describe what the codes represent - removed f-string that wasn't exporting with older version of Babel as it wasn't needed IMPORTANT: as of saas-18.2, xml translations are possible, but as the current status of the script to convert po translations into xml transations is insufficient for handling fw-porting of Translations, they have been reverted for the Belgian/Swiss payroll localizations. Issues when attempting to use script included: - does not remove existing xml translations - only appears to apply translations to the first translateable term in the xml record (i.e. the `hr.contract.salary.benefit` translations for `description` and `fold_label` are lost) Additionally, by leaving the translations all within the pot/po files, minimal manual work will be needed to fw-port the translations due to more consistent code between versions. Will fix opw-4614757 Forward-Port-Of: odoo/enterprise#82009

Issue: In Barcode, performing certain operations and then reverting your changes can drastically affect the state of records: "picked" status or the visual demand of the move. ### Steps to reproduce: - Create a storable product tracked by SN. Put 2 SN in stock SN1 and SN2 - Create a delivery order for 2 units and mark as to do. > The two SN's should be reserved on your delivery. - Go to the barcode app, scan SN1. - Edit edit the SN1 line to set the qty back to 0. - Leave the barcode app and come back to the record. #### > The subline related to SN1 displays now a demand of 0. A new barcode line has been created with a demand of 1 for SN1. In short an extra record was created unecessarily. ### Cause of the issue: In the barcode app the demand of each line is measured by the quantity present on its move lines. In our set up, the move is related to 2 moves lines with a quantity of 1 that are not picked. Scanning SN1 will update the qty_done of its line to 1. As such, the move line quantity will be set from 1 to 1 and the move line will be picked: https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move_line.py#L58-L61 In turns, the picked state of the move will be set to picked: https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/stock/models/stock_move.py#L208-L212 Now, editing the qty done of the move once more from 1 to 0 to reset the reservation will not revert the process for 2 reasons: 1. The quantity of the move line will be reset form its current value to 0, altering the demand of the barcode line to 0. 2. Even if the move line was unpicked in this process, the picked compute method of the move will never reset the picked state as the compute method can only set a True value. We therefore end up with a picked move without any picked move line and for which one of the picked move line has a quantity of 0. Now, leaving the barcode app will launch the split_uncompleted_moves method in order to not lose the changes made to the record and since the move is picked for the wrong reason, the move will be splitted in 2 instead of escaping the split process. https://github.com/odoo/enterprise/blob/e8c831a540c12019c560cc19abf7abe8785d0e0e/stock_barcode/models/stock_move.py#L21-L22 Community: https://github.com/odoo/odoo/pull/200167 opw-4600565 Forward-Port-Of: odoo/enterprise#81909 Forward-Port-Of: odoo/enterprise#80675

__Steps to reproduce:__ - Navigate to *Working Schedules* > *Standard 40 hours/week* - Remove the Lunch period - Create overlapping `Morning` and `Afternoon` periods on multiple days - Example: Morning: `08:00` to `12:00`, Afternoon: `12:00` to `16:00` - Go to *Planning* > *New* - Generate a slot within this period as an open shift - Go to the next week and select *Copy previous week* - Traceback error appears: - `TypeError: '<' not supported between instances of 'NoneType' and 'datetime.datetime'` __Description of the issue:__ - In Planning, `calender._attendance_intervals_batch` function returns dict() of `workInterval`, which does not merge overlapping intervals. The `_merge` function in `Intervals` assumes input intervals are already merged, This mismatch caused issues in the planning app when unmerged overlapping intervals were passed to `_merge` __Description of the solution:__ - Convert `workInterval` instances to `Intervals` by passing `workInterval._items` directly to `Intervals`, as it performs merging on overlapping intervals during instantiation. - bug introduced in: [#f283540][1] - opw-4282039 [1]:https://github.com/odoo/odoo/commit/f283540336b29037fe8af9c1a951c3d27c941b3d#diff-357c95d58ea67c00f24d3a4c5a8a987041c42de13ca9f5535e7bb250b2927af6L214 Forward-Port-Of: odoo/enterprise#78499 Forward-Port-Of: odoo/enterprise#73618

Bug Fixes(7)

[FIX] html_editor: prevent infinite loop in link tools

[FIX] base: traceback server action

[FIX] hr_expense: search view use ilike instead of =like

[FIX] base: cron auto-vacuum race

[FIX] hr_appraisal: report state

[FIX] sign: post merge ui fixes

[FIX] account_reports_cash_basis: fix duplicate account code

Other(54)

[FW][IMP] web: log exports

Bug Fixes(7)

[FIX] html_editor: prevent infinite loop in link tools

[FIX] base: traceback server action

[FIX] hr_expense: search view use ilike instead of =like

[FIX] base: cron auto-vacuum race

[FIX] hr_appraisal: report state

[FIX] sign: post merge ui fixes

[FIX] account_reports_cash_basis: fix duplicate account code

Other(54)

[FW][IMP] web: log exports

[FW][PERF] product: speedup product.attribute _compute_products

[FW][FIX] account: reset payment without JE on unreconcile of the statement

[FW] 17.0 escertchange jco

[FW][IMP] account: validate mandatory analytic plans when batch posting

[FW][FIX] point_of_sale: prevent duplicate lot numbers on receipts

[FW][FIX] discuss: prevent traceback when missing channel in call

[FW][FIX] html_editor: prevent scroll on partially visible elements

[FW][FIX] partner_autocomplete: can unset partner many2one field

[FW][FIX] hr_holidays: fix allocation without employee

[FW][FIX] stock{,_barcode}: avoid extra moves and demand updates

[FW][FIX] web: hide pager when sample data is displayed

[FW][FIX] pos_loyalty: fix incorrect grammar

[FW][IMP] pos_loyalty: exclude loyalty points for UrbanPiper orders

[FW][FIX] point_of_sale: allow coins/bills to have greater accuracy

[FW][FIX] l10n_be_pos_sale : allow loading pos from child company

[FW][FIX] mail: no access to reactions for public users

[FW][FIX] web: proper interpolation in CSS custom properties

[FW][FIX] l10n_din5008: Fix overlapping adresses

[FW][FIX] sale: don't discount fixed taxes

[FW][FIX] base: add missing attributes to STMPConnection

[FW][FIX] pos_self_order_stripe: fix traceback

[FW][PERF] stock: speedup get_orderpoint_action

[FW][FIX] im_livechat: access error after operator left

[FW][FIX] website: prevent traceback when no `.s_tabs_nav .nav` exists

[FW][PERF] stock: prevent unecessary writes

[FW][FIX] web: reuse same image url if the related field on same model

[FW][FIX] point_of_sale, pos_*: shared self order when same table

[FW][FIX] mail: prevent user from being re-added to channel after leaving

[FW][FIX] core: fix werkzeug version parsing

[FW][FIX] pos_event: prevent error on installing module

[FW][FIX] sale: corrected calculation of the uninvoiced balance field

[FW][FIX] account: sequence prefix with concurrency

[FW][I18N] {documents}_l10n_{be,ch}_hr_*: fw-port translations

[FW][PERF] sale_subscription: Inverse domain on subs' state for main action

[FW][FIX] account_accountant_batch_payment: test reset of batch payment

[FW][IMP] account_asset: add missing column

[FW][FIX] l10n_de_pos_cert: fix empty receipt

[FW][FIX] hr_contract_salary: correct the visual of signatures at kanban

[FW][FIX] helpdesk: Propagate `onWillSaveRecord` override correctly

[FW][FIX] l10n_be_hr_payroll: adapt simulation values

[FW][FIX] stock{,_barcode}: avoid extra moves and demand updates

[FW][FIX] l10n_nl_reports_sbr{_icp}: keep previous XBRL version

[FW][FIX] l10n_de_pos_res_cert: prevent IndexError when splitting orders

[FW][FIX] l10n_nl_reports_vat_pay_wizard: no belastingdienst account

[FW][FIX] sign: translate model description in rendered mail templates

[FW][FIX] web_studio: proper interpolation in CSS custom properties

[FW][IMP] l10n_hk_hr_payroll: hk payslip report improvements

[FW][FIX] Planning: change the return type of attendances into Intervals

[FW][FIX] account_accountant: bank rec widget alignment issue

[FW][FIX] approvals: list request owner based on selected companies

[FW][FIX] l10n_mx_edi: allow cancel payment

[FW][FIX] delivery_fedex_rest: fix incorrect state codes and field lengths

[FW][FIX] l10n_es_real_estates, l10n_es_reports: fixed boe key map of real estates invoices