Odoo Changelog — 2025-07-15

Tuesday, July 15, 2025

10 changes · saas-18.1

Bug Fixes(10)

Resolved issues and error corrections

[FIX] hr_holidays: fix traceback when creating a leave request

Coresaas-18.1hr_holidaysMedium

Fixes an error that could appear when creating or editing a Time Off request after switching the selected employee. This helps HR users complete leave requests reliably when multiple employees share the same leave type allocation.

Original PR description

Currently, a traceback occurrs when creating a leave request for an employee

**To reproduce this issue in 18.0:**

1) Install hr_holidays
2) Navigate to Time Off > Management > Allocations. 
3) Create an allocation for 2 employees with same leave type 
4) Navigate to Time Off > Management > Time Off.
5) Create a new time off  for employye1, with above leave type 
6) Now, change the employee to employee2

**Error:-**
```
'hr.leave.allocation' object has no attribute 'virtual_remaining_leaves'
```

**Cause:-**

The field `virtual_remaining_leaves` is  present in `hr.leave.type`, 
it was introduced from saas~18.3 in `hr.leave.allocation`.
https://github.com/odoo/odoo/commit/944c11e61abead4f5157a7a7cb7b1f536bc14411#diff-3a9cd2e66cdd2827ecf6d9e693aff35eeacdfaaa68875b7b2572edde23b757eaR123

So indeed a traceback will occur when trying to access `virtual_remaining_leaves` 
from allocation from the below line. 

https://github.com/odoo/odoo/blob/97f9ad816cb4b35aa2d4713038cc2c623dfaf176/addons/hr_holidays/models/hr_leave_type.py#L168-L170

**Solution:-**

Since the value of `virtual_remaining_leaves` is retrieved from the same method 
(_get_consumed_leaves) for both `hr.leave.type` and `hr.leave.allocation` in 18.3, 
So we can use the value of `virtual_remaining_leaves` from `hr.leave.type`.

opw-4860637,4868969

Forward-Port-Of: odoo/odoo#216436
Forward-Port-Of: odoo/odoo#214709

#time off#leave requests#allocations

[FIX] web: avoid reloading the Kanban view when exiting

PR #218988

Coresaas-18.1webMedium

Fixes an issue where the project creation dialog could sometimes remain stuck on screen after creating a new project. Users can now complete project creation and continue working without needing to refresh or work around an unresponsive dialog.

Original PR description

- Open a Project;
- Create a new project;

Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and especially [2], we waited for the view to reload before closing the dialog. However, while the view was reloading, it was destroyed and replaced by the Kanban view of the tasks of the new project. This meant that the reload promise was never resolved. Consequently, the code that actually closes the dialog [3] was never reached, as `await onClose?.(closeParams)` was never resolved.

[1] https://github.com/odoo/odoo/pull/202512
[2] [d606be7](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686)
[3] [d606be7#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318)

opw-4880968

[FIX] account: prevent company currency update

PR #218882

Coresaas-18.1accountMedium

This fix prevents users from changing another company's currency once that company already has journal entries. It helps protect accounting data consistency when users work across multiple companies.

Original PR description

To_reproduce:
==============
1- switch company.
2- update any other company currency that has journal items. 3- company currency changed.

Problem:
=========
- When switching companies, users could update the other company's currency even when journal items existed for that company. Solution:

Solution:
=========
- Added .sudo() to the account.move.line search to bypass access rights and properly detect existing journal items in that company.

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

Forward-Port-Of: odoo/odoo#218473
Forward-Port-Of: odoo/odoo#217929

#currency#multi-company#accounting

[FIX] account_edi_ubl_cii: use `deferred_start/end_date` in FacturX XML

PR #218888

Coresaas-18.1account_edi_ubl_ciiMedium

Factur-X electronic invoices now use the deferred start and end dates from invoice lines when those dates are available. This helps ensure the XML invoice reflects the actual service period, improving accuracy for customers and compliance workflows.

Original PR description

### Issue:
The FacturX XML has a field `BillingSpecifiedPeriod`, it should depend on `deferred_start/end_date` if they are there. Currently, it only outputs the invoice date as start date and the due date as end date.

### Steps to reproduce:
- Install "l10n_de" and switch to a German company
- Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)"
- Create an invoice for this contact
- Add a start date and end date on the line of this invoice (`deferred_start/end_date`)
- Confirm and send to Factur-X
- In the generated XML the dates used are the invoice date and the due date

### Cause:
As the `deferred_start/end_date` fields are defined in enterprise and the XML generation is in community, this [commit](https://github.com/odoo/odoo/commit/f0c5d5b46444a289bf55ad5846623d48ac3a3b71) set dates defined in community instead of the deferred ones.

### Solution:
Mimicking [the way it's done for UBL20](https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L846) we check if  `deferred_start/end_date` are defined (i.e. account_accountant is installed). If it's the case, we use the min/max of the `deferred_start/end_date` as start/end date of the `BillingSpecifiedPeriod` in the XML.

To include as much info as we can this commit also adds the `deferred_start_date` and `deferred_end_date` on lines.

opw-4874370

Forward-Port-Of: odoo/odoo#218340
Forward-Port-Of: odoo/odoo#215595

[FIX] hw_drivers: send_all_devices condition fix

PR #218237

Coresaas-18.1hw_driversMedium

IoT boxes now notify Odoo when their own connection details change, not only when new devices are discovered. This keeps the database up to date with IP address, hostname, MAC address, domain, and version changes, including more reliable IP detection on Windows.

Original PR description

Currently we notify the database of any iot changes only if the iot box discovered new devices.
However if its ip address/hostname/mac address/domain/version change the db is never notified.

This PR adds this change + fixes the get_ip() method which was using netifaces which is unreliable on Windows to now use socket to get the iot box ip address

Forward-Port-Of: odoo/odoo#218109

#iot#devices#network#windows

[FIX] l10n_tr_nilvera_einvoice: move InvoicePeriod element in XML

PR #219031

Coresaas-18.1l10n_tr_nilvera_einvoiceMedium

This fix updates Turkish Nilvera e-invoice XML so subscription invoice periods are placed at the document level, matching the required UBL TR format. It also prevents sending invoices when subscription line dates conflict, helping avoid rejected e-invoices and compliance issues.

Original PR description

The UBL TR 1.2.1 format does not support \<InvoicePeriod\> element in invoice lines in the XML
generated for e-invoice.
This commit moves the \<InvoicePeriod\> element from invoice lines to document level.
It also validates that the start and end dates of all subscription invoice lines in one invoice should
be same, or else it shows warning and disables the `Send & Print` wizard button

TaskId:4885865


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

Forward-Port-Of: odoo/odoo#218820
Forward-Port-Of: odoo/odoo#215819

#turkey#e-invoicing#compliance#subscriptions

[FIX] account: improve invoice summary label when reconciled with non-payments

PR #218979

Coresaas-18.1accountMedium

Invoice summaries now show “Reversed on ...” when an invoice is reconciled through a credit note instead of incorrectly saying it was paid. This helps users distinguish real payments from reversals and avoids misleading accounting information.

Original PR description

Before this PR:
-------------------------------------------------- 
In the invoice summary, the label `Paid on ...` was always shown whenever the invoice was reconciled, regardless of whether the reconciliation was made through an actual payment (bank/cash) or through a credit note or journal entry.

This led to misleading information:
- Credit note reconciliation (partial or full) showed `Paid on ...`
- Even though no real payment occurred
- Full reversals correctly showed status 'Reversed', but the label still said `Paid on ...`

After this PR:
--------------------------------------------------
- The label is now shown as `Reversed on ...` when the reconciliation is done with credit note.
- This avoids confusion and better reflects the actual accounting status of the invoice

This change ensures users are not misled by incorrect payment indications when only a reversal or credit note is involved.

task-4920349

Forward-Port-Of: odoo/odoo#217477

#invoice#reconciliation#credit-note#accounting

[FIX] calendar, google_calendar: email reminders fixes

PR #219157

Coresaas-18.1calendargoogle_calendarmicrosoft_calendarMedium

Odoo now avoids sending invitation, update, or reminder emails for calendar events that have already ended or are managed by an external calendar. This reduces duplicate or unnecessary notifications for users syncing events with Google or Microsoft calendars.

Original PR description

Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over.

When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders.

Recently, we had to revert the two original PRs due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back.


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

Forward-Port-Of: odoo/odoo#219060

#calendar#email reminders#google calendar#microsoft calendar#sync

[FIX] account_asset: consider imported depreciated amount

PR #90188

Enterprisesaas-18.1account_assetl10n_in_assetMedium

When companies migrate assets into Odoo, previously depreciated amounts are now included correctly in depreciation totals and schedule reports. This helps finance teams see accurate asset values after migration without duplicating old journal entries.

Original PR description

Working:-
-  When migrating from any other accounting software to Odoo,in
  `Depreciated Amount(already_depreciated_amount_import)` field we put asset's
   depreciated amount till then(before migration). This depreciation is recorded
   in each account when starting in Odoo(the original balances) and in Odoo
   creating Journal Entries are skipped for this imported depreciated amount.

Example:-
- Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020,
  Method: Straight Line, Duration: 10 Years, Computation: No Prorata.
- Now according to our computation this asset will depreciate \$1000.00 for the
  years 2020 to 2029 each, and Journal Entries would be created on 31st December
  each year.
- Now someone migrating from other software to Odoo in the year 2025 will put
  Depreciated Amount: \$5,000.00 .
- Now Odoo will create Journal Entries for only years 2025 to 2029 and skip
  creating Journal Entries for the years 2020 to 2024 as these entries are
  created in previous accounting package and are recorded in original balances
  while migrating.

Before this commit:-
- In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the
  year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported
  depreciated amount.
- Depreciation Schedule report displays constant \$5,000.00 as depreciated value
  for the years 2020 to 2024.

After this commit:-
- In Depreciation Board, imported depreciated amount is added in Cumulative
  Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till
  \$10,000.00 for the year 2029.
- In Depreciation Schedule Report, `_simulate_imported_depreciation` method will
  modify report values to simulated imported depreciation amount and skipped
  Journal Entries.

task-4864528

Forward-Port-Of: odoo/enterprise#90052
Forward-Port-Of: odoo/enterprise#88127

[FIX] account_online_synchronization: prevent error by passing correct journal_type

PR #89863

Enterprisesaas-18.1account_online_synchronizationMedium

Connecting a new bank account from Invoicing no longer fails due to an internal data mismatch. This helps users complete bank setup smoothly and reduces support incidents during online synchronization onboarding.

Original PR description

Currently, an error occurs when attempting to connect a new bank account. **Step to produce:** - Install the `account_online_synchronization` module and open `invoicing`. - Go to: `Configuration >…

Currently, an error occurs when attempting to connect a new bank account.

**Step to produce:**

- Install the `account_online_synchronization` module and open `invoicing`.
- Go to: `Configuration > Banks > Add a Bank Account`.
- `Add new bank > Enter Details > Connect`.

**Error:**
`AssertionError: null`

**Root Cause:**
At [1], the JS component incorrectly passes `journalType` as a `dictionary`,
while at [2], the Python method expects a `string value (journal_type)`, which 
causes an Error.

[1]
https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/static/src/js/odoo_fin_connector.js#L63-L68
[2]
https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/models/account_online.py#L419-L420

This commit prevents the error by ensuring only the expected `journal_type` 
passes from the `orm call`, similar to [3].

[3]
https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L68-L76

sentry–6735152390

Currently, a traceback occurrs when creating a leave request for an employee **To reproduce this issue in 18.0:** 1) Install hr_holidays 2) Navigate to Time Off > Management > Allocations. 3) Create an allocation for 2 employees with same leave type 4) Navigate to Time Off > Management > Time Off. 5) Create a new time off for employye1, with above leave type 6) Now, change the employee to employee2 **Error:-** ``` 'hr.leave.allocation' object has no attribute 'virtual_remaining_leaves' ``` **Cause:-** The field `virtual_remaining_leaves` is present in `hr.leave.type`, it was introduced from saas~18.3 in `hr.leave.allocation`. https://github.com/odoo/odoo/commit/944c11e61abead4f5157a7a7cb7b1f536bc14411#diff-3a9cd2e66cdd2827ecf6d9e693aff35eeacdfaaa68875b7b2572edde23b757eaR123 So indeed a traceback will occur when trying to access `virtual_remaining_leaves` from allocation from the below line. https://github.com/odoo/odoo/blob/97f9ad816cb4b35aa2d4713038cc2c623dfaf176/addons/hr_holidays/models/hr_leave_type.py#L168-L170 **Solution:-** Since the value of `virtual_remaining_leaves` is retrieved from the same method (_get_consumed_leaves) for both `hr.leave.type` and `hr.leave.allocation` in 18.3, So we can use the value of `virtual_remaining_leaves` from `hr.leave.type`. opw-4860637,4868969 Forward-Port-Of: odoo/odoo#216436 Forward-Port-Of: odoo/odoo#214709

- Open a Project; - Create a new project; Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and especially [2], we waited for the view to reload before closing the dialog. However, while the view was reloading, it was destroyed and replaced by the Kanban view of the tasks of the new project. This meant that the reload promise was never resolved. Consequently, the code that actually closes the dialog [3] was never reached, as `await onClose?.(closeParams)` was never resolved. [1] https://github.com/odoo/odoo/pull/202512 [2] [d606be7](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686) [3] [d606be7#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318) opw-4880968

To_reproduce: ============== 1- switch company. 2- update any other company currency that has journal items. 3- company currency changed. Problem: ========= - When switching companies, users could update the other company's currency even when journal items existed for that company. Solution: Solution: ========= - Added .sudo() to the account.move.line search to bypass access rights and properly detect existing journal items in that company. opw-4920206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218473 Forward-Port-Of: odoo/odoo#217929

### Issue: The FacturX XML has a field `BillingSpecifiedPeriod`, it should depend on `deferred_start/end_date` if they are there. Currently, it only outputs the invoice date as start date and the due date as end date. ### Steps to reproduce: - Install "l10n_de" and switch to a German company - Go to a contact, in the page Accounting > Electronic Invoicing change the format to "Factur-X (CII)" - Create an invoice for this contact - Add a start date and end date on the line of this invoice (`deferred_start/end_date`) - Confirm and send to Factur-X - In the generated XML the dates used are the invoice date and the due date ### Cause: As the `deferred_start/end_date` fields are defined in enterprise and the XML generation is in community, this [commit](https://github.com/odoo/odoo/commit/f0c5d5b46444a289bf55ad5846623d48ac3a3b71) set dates defined in community instead of the deferred ones. ### Solution: Mimicking [the way it's done for UBL20](https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L846) we check if `deferred_start/end_date` are defined (i.e. account_accountant is installed). If it's the case, we use the min/max of the `deferred_start/end_date` as start/end date of the `BillingSpecifiedPeriod` in the XML. To include as much info as we can this commit also adds the `deferred_start_date` and `deferred_end_date` on lines. opw-4874370 Forward-Port-Of: odoo/odoo#218340 Forward-Port-Of: odoo/odoo#215595

Currently we notify the database of any iot changes only if the iot box discovered new devices. However if its ip address/hostname/mac address/domain/version change the db is never notified. This PR adds this change + fixes the get_ip() method which was using netifaces which is unreliable on Windows to now use socket to get the iot box ip address Forward-Port-Of: odoo/odoo#218109

The UBL TR 1.2.1 format does not support \<InvoicePeriod\> element in invoice lines in the XML generated for e-invoice. This commit moves the \<InvoicePeriod\> element from invoice lines to document level. It also validates that the start and end dates of all subscription invoice lines in one invoice should be same, or else it shows warning and disables the `Send & Print` wizard button TaskId:4885865 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218820 Forward-Port-Of: odoo/odoo#215819

Before this PR: -------------------------------------------------- In the invoice summary, the label `Paid on ...` was always shown whenever the invoice was reconciled, regardless of whether the reconciliation was made through an actual payment (bank/cash) or through a credit note or journal entry. This led to misleading information: - Credit note reconciliation (partial or full) showed `Paid on ...` - Even though no real payment occurred - Full reversals correctly showed status 'Reversed', but the label still said `Paid on ...` After this PR: -------------------------------------------------- - The label is now shown as `Reversed on ...` when the reconciliation is done with credit note. - This avoids confusion and better reflects the actual accounting status of the invoice This change ensures users are not misled by incorrect payment indications when only a reversal or credit note is involved. task-4920349 Forward-Port-Of: odoo/odoo#217477

Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. Recently, we had to revert the two original PRs due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-4684432, 4316693 Forward-Port-Of: odoo/odoo#219060

Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration). This depreciation is recorded in each account when starting in Odoo(the original balances) and in Odoo creating Journal Entries are skipped for this imported depreciated amount. Example:- - Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020, Method: Straight Line, Duration: 10 Years, Computation: No Prorata. - Now according to our computation this asset will depreciate \$1000.00 for the years 2020 to 2029 each, and Journal Entries would be created on 31st December each year. - Now someone migrating from other software to Odoo in the year 2025 will put Depreciated Amount: \$5,000.00 . - Now Odoo will create Journal Entries for only years 2025 to 2029 and skip creating Journal Entries for the years 2020 to 2024 as these entries are created in previous accounting package and are recorded in original balances while migrating. Before this commit:- - In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported depreciated amount. - Depreciation Schedule report displays constant \$5,000.00 as depreciated value for the years 2020 to 2024. After this commit:- - In Depreciation Board, imported depreciated amount is added in Cumulative Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till \$10,000.00 for the year 2029. - In Depreciation Schedule Report, `_simulate_imported_depreciation` method will modify report values to simulated imported depreciation amount and skipped Journal Entries. task-4864528 Forward-Port-Of: odoo/enterprise#90052 Forward-Port-Of: odoo/enterprise#88127

Currently, an error occurs when attempting to connect a new bank account. **Step to produce:** - Install the `account_online_synchronization` module and open `invoicing`. - Go to: `Configuration > Banks > Add a Bank Account`. - `Add new bank > Enter Details > Connect`. **Error:** `AssertionError: null` **Root Cause:** At [1], the JS component incorrectly passes `journalType` as a `dictionary`, while at [2], the Python method expects a `string value (journal_type)`, which causes an Error. [1] https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/static/src/js/odoo_fin_connector.js#L63-L68 [2] https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/models/account_online.py#L419-L420 This commit prevents the error by ensuring only the expected `journal_type` passes from the `orm call`, similar to [3]. [3] https://github.com/odoo/enterprise/blob/08d7056596c1cab97437dbc4ed9b5bbb26bf7ad3/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L68-L76 sentry–6735152390