Odoo Changelog — 2026-02-07

Saturday, February 7, 2026

9 changes · 19.0

Bug Fixes(9)

Resolved issues and error corrections

[FIX] sign: prevent access error for sample template

Enterprise19.0sign

This update resolves an issue where users with limited sign rights couldn't access the sample document template. The fix ensures that users can now successfully create and manage sign items within the sample template, improving usability for all users. This change corrects a security-related access restriction.

Original PR description

**Issue**
Users without 'Admin' Sign rights could in some cases not access the sample template.

**Steps to reproduce**
1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it.
2. Add some sign items to the template, and send it for a signature request.
3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'.

Access Error:
Blame the following rules:
- sign.item: group_sign_user: Create and manage template items

**Cause**
When the template has an associated sign request, it is copied.
The problem is that the user currently doesn't have enough rights
to create sign items for the copied template:
https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101

**Change**
Change the `user_id` of the new template to allow creating the
sign items for it. The user also needs write access to the roles
of the sign items. Also make sure to properly remove the sign
items from the new template.

opw-5254566

Forward-Port-Of: odoo/enterprise#105558
Forward-Port-Of: odoo/enterprise#102227

#sign#template#access

[FIX] account_asset: avoid SQL error on unsaved records with non-deductible tax

PR #106736

Enterprise19.0account_asset

This update resolves a technical issue that caused a SQL error when creating invoices with non-deductible taxes in Studio. The fix prevents the error by skipping the problematic SQL query when invoice lines are not yet saved, ensuring smoother invoice creation.

Original PR description

**Steps to reproduce:**
* Install **account_asset** and **l10n_be**.
* Enable **developer mode**.
* Using **Studio**, add the field **non_deductible_tax_value** to invoice lines.
* Create a new invoice.
* Select a partner and add a product with **21% VAT** applied.
* Do not save the invoice before adding the line.

**Observed behavior:**
* A **SQL syntax error** occurs: `WHERE tdq.base_line_id IN ()`.
* The error is triggered when accessing the non-deductible tax value on unsaved records.

**Cause:**
* `_compute_non_deductible_tax_value()` executes SQL query with `tuple(self.ids)`.
* For unsaved records, `self.ids` is empty, creating invalid SQL `IN ()` syntax.
* This path is only reached for **non-deductible taxes**.

**Fix:**
* Skip the SQL query when no record IDs are available.
* Return a default value for unsaved records.

opw-5896716

Forward-Port-Of: odoo/enterprise#106655
Forward-Port-Of: odoo/enterprise#106470

#invoice#tax#error

[FIX] pos_self_order_iot: handle terminal transaction timeout

PR #106731

Enterprise19.0pos_self_order_iotMEDIUM

This update resolves an issue where kiosk transactions would freeze if a terminal sent a 'cancel' signal. Now, the system treats this 'cancel' event as an error, allowing users to restart their transaction and ensuring a smoother checkout experience. This improves kiosk usability and prevents user frustration.

Original PR description

If the transaction isn't handled after some time, the terminal itself sends a cancelation event.

As the kiosk doesn't handle cancelations, it results in the user being stuck with "Follow instructions on the terminal", but the terminal not processing any transaction anymore.

We now treat the "cancel" event as an error to allow the user restart the transaction.

#kiosk#pos#transaction#error handling

[FIX] account_accountant: prevent commit cursor during import bank transactions

PR #106780

Enterprise19.0account_accountantMEDIUM

This update resolves an issue that caused bank transaction imports to fail when processing files with over 80 lines. The fix prevents unnecessary database commits during the import process, ensuring stability and reliable import of larger transaction sets. This improves the user experience when importing bank statements.

Original PR description

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810

Forward-Port-Of: odoo/enterprise#102760

#bank#import#transactions

[FIX] spreadsheet_edition: cell thread display_name

PR #106779

Enterprise19.0spreadsheet_editionMEDIUM

This update resolves a technical error that was preventing the correct display of names within Odoo's spreadsheet feature. The change ensures that spreadsheet cell threads only use a single name, preventing a crash and improving stability. This update is a critical fix for proper spreadsheet functionality.

Original PR description

**Before this change**
We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets.

**After this change**
We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value.

opw-5380947

Forward-Port-Of: odoo/enterprise#106673
Forward-Port-Of: odoo/enterprise#106230

#spreadsheet#performance#stability

[FIX] account_reports: prevent division by zero error in aggregate formulas

PR #106787

Enterprise19.0account_reportsMEDIUM

This update resolves an issue where accounting reports would crash when encountering a zero denominator in calculations. The fix ensures that formulas are handled correctly, preventing errors and improving the stability of the Deferred Revenue report. This ensures accurate reporting for users.

Original PR description

Currently, an error occurs when opening an `accounting report` when the evaluated data produces a `zero denominator` during formula computation. **Steps to reproduce:** - Install the…

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

#reporting#accounting#error

[FIX] l10n_sg_reports: fix error on IRAS audit file generation

PR #106798

Enterprise19.0l10n_sg_reportsMEDIUM

This update resolves an error that prevented the generation of IRAS Audit Files for Singapore companies. The fix corrects a coding issue that caused a 'TypeError' during the file creation process, ensuring accurate reporting for Singapore businesses.

Original PR description

Currently, an error occurs when generating the `IRAS Audit File` for a `Singapore` company **Steps to reproduce:** - Install the `l10n_sg_reports` and `accountant` modules (without demo data). -…

Currently, an error occurs when generating the `IRAS Audit File` for 
a `Singapore` company

**Steps to reproduce:**
- Install the `l10n_sg_reports` and `accountant` modules (without demo data).
- Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, 
  then switch to this company.
- Navigate to Accounting > Reporting > Singapore > IRAS Audit File.
- Fill in the required details and click `Generate`.

**Error:**
`TypeError: 'account.account' object is not callable`

**Root cause:**
After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` 
without arguments and then attempts to call the returned recordset with 
`line_account_ids`. Since `browse()` already returns a recordset, this results 
in calling an `account.account` recordset as a `function`, causing an `error`.

**Fix:**
This commit prevents an error during IRAS Audit File generation by correcting 
the `browse()` call to pass `line_account_ids` directly as its argument.

[1]:
https://github.com/odoo/enterprise/pull/72675

[2]:
https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210

opw-5877947

Forward-Port-Of: odoo/enterprise#106150

#reporting#singapore# IRAS

[FIX] l10n_ch_hr_payroll_elm_transmission: Unlock snapshot before updating

PR #106446

Enterprise19.0l10n_ch_hr_payroll

This update resolves an issue where canceling a payslip could lead to inconsistencies in data updates. By unlocking snapshots before updating, the system now maintains more accurate and reliable payroll information. This ensures data integrity and reduces the risk of errors during payslip management.

Original PR description

When canceling a payslip, we now unlock the snapshots before updating them to improve consistency

Forward-Port-Of: odoo/enterprise#106439

#payroll#data integrity#consistency

[FIX] appointment_crm: correct lead activity deadline for future appts

PR #106820

Enterprise19.0appointment_crmMEDIUM

This update fixes an issue where future appointments created in the system incorrectly set the lead's activity deadline to today's date. The fix ensures that the activity deadline aligns with the appointment's scheduled date, improving the accuracy of opportunity tracking. This change was made to enhance the usability of the appointment scheduling feature.

Original PR description

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date. ### Steps to reproduce - Install…

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.

opw-5780578

Forward-Port-Of: odoo/enterprise#106770
Forward-Port-Of: odoo/enterprise#106162

#appointments#crm#lead activity

**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it. 2. Add some sign items to the template, and send it for a signature request. 3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'. Access Error: Blame the following rules: - sign.item: group_sign_user: Create and manage template items **Cause** When the template has an associated sign request, it is copied. The problem is that the user currently doesn't have enough rights to create sign items for the copied template: https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101 **Change** Change the `user_id` of the new template to allow creating the sign items for it. The user also needs write access to the roles of the sign items. Also make sure to properly remove the sign items from the new template. opw-5254566 Forward-Port-Of: odoo/enterprise#105558 Forward-Port-Of: odoo/enterprise#102227

**Steps to reproduce:** * Install **account_asset** and **l10n_be**. * Enable **developer mode**. * Using **Studio**, add the field **non_deductible_tax_value** to invoice lines. * Create a new invoice. * Select a partner and add a product with **21% VAT** applied. * Do not save the invoice before adding the line. **Observed behavior:** * A **SQL syntax error** occurs: `WHERE tdq.base_line_id IN ()`. * The error is triggered when accessing the non-deductible tax value on unsaved records. **Cause:** * `_compute_non_deductible_tax_value()` executes SQL query with `tuple(self.ids)`. * For unsaved records, `self.ids` is empty, creating invalid SQL `IN ()` syntax. * This path is only reached for **non-deductible taxes**. **Fix:** * Skip the SQL query when no record IDs are available. * Return a default value for unsaved records. opw-5896716 Forward-Port-Of: odoo/enterprise#106655 Forward-Port-Of: odoo/enterprise#106470

If the transaction isn't handled after some time, the terminal itself sends a cancelation event. As the kiosk doesn't handle cancelations, it results in the user being stuck with "Follow instructions on the terminal", but the terminal not processing any transaction anymore. We now treat the "cancel" event as an error to allow the user restart the transaction.

*= account_bank_statement_import_csv An exception is currently triggered when a user attempts to import a bank transaction file containing more than 80 transaction lines (see ref file [1]). Steps to produce an error: - Install `Accounting (accountant)` module - Go to `Accounting` > Click on `Bank` > Click `Upload` - Upload ref file [1] and click `Test/Import` >>> Error occurs Error: `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update` Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f -11f0-bc75-74563c5c983f" does not exist` The issue occurs because, in `model.py` code line [2] creates a `savepoint`. Before this `savepoint` is closed, code line [3] is triggered during the creation of the bank statement line [4] and attempts to commit the cursor using `self.env.cr.commit()`. Because a commit is executed while the savepoint is still active, the system fails when trying to close the previously created savepoint. This commit fixes the issue by avoiding cursor commits during the import process. The `import_file=True` flag is added to the context when `_cron_try_auto_reconcile_statement_lines` is called from `execute_import`, allowing the method to safely skip commit/rollback logic when `import_file` is present in the context. [1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true [2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973 [3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218 [4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780 sentry-6974536471 opw-5359810 Forward-Port-Of: odoo/enterprise#102760

**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947 Forward-Port-Of: odoo/enterprise#106673 Forward-Port-Of: odoo/enterprise#106230

Currently, an error occurs when opening an `accounting report` when the evaluated data produces a `zero denominator` during formula computation. **Steps to reproduce:** - Install the `account_reports` module (without demo) and enable `developer mode`. - Navigate to Accounting > Reporting > Deferred Revenue. - Click the `gear icon` to open the report configuration. - Click `Add a line` to create a new report line. - Click `Add a line` to create a new expression with: >- Computation Engine: `Aggregate Other Formulas` >- Formula: `0/0` - Save the new expression and report line. - Try to reopen the `Deferred Revenue`. **Error:** `ZeroDivisionError: division by zero` **Root Cause:** After commit [1], at [2], expressions without the `ignore_zero_division` subformula are evaluated in the else condition, causing an error when the `denominator is zero`. **Fix:** This commit prevents errors caused by zero denominators during formula evaluation and improves the clarity of the resulting error messages. [1]: https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0 [2]: https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547 opw-5475146 Forward-Port-Of: odoo/enterprise#103773

Currently, an error occurs when generating the `IRAS Audit File` for a `Singapore` company **Steps to reproduce:** - Install the `l10n_sg_reports` and `accountant` modules (without demo data). - Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, then switch to this company. - Navigate to Accounting > Reporting > Singapore > IRAS Audit File. - Fill in the required details and click `Generate`. **Error:** `TypeError: 'account.account' object is not callable` **Root cause:** After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` without arguments and then attempts to call the returned recordset with `line_account_ids`. Since `browse()` already returns a recordset, this results in calling an `account.account` recordset as a `function`, causing an `error`. **Fix:** This commit prevents an error during IRAS Audit File generation by correcting the `browse()` call to pass `line_account_ids` directly as its argument. [1]: https://github.com/odoo/enterprise/pull/72675 [2]: https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210 opw-5877947 Forward-Port-Of: odoo/enterprise#106150

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date. ### Steps to reproduce - Install `appointment_crm`. - Go to Appointments > Schedule > Staff Booking. - Create a booking for a future date (e.g., next month) and add a customer. - Confirm the booking. - Open the newly created Opportunity. - Check the "Next Activity" deadline. - It is set to today's date instead of the appointment's date. ### Cause The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity. When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`. Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline. ### Fix Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`. opw-5780578 Forward-Port-Of: odoo/enterprise#106770 Forward-Port-Of: odoo/enterprise#106162