Odoo Changelog — 2026-06-26

Friday, June 26, 2026

8 changes · 19.0

Bug Fixes(8)

Resolved issues and error corrections

[FIX] l10n_ph_reports: include child tax tags in generic report queries

Enterprise19.0l10n_ph_reportsMEDIUM

This fix ensures invoice lines are properly included in tax reports when grouped taxes are used. It now recognizes the relevant child tax tags, so report totals are more accurate and no longer miss lines tied to those taxes.

Original PR description

When using group taxes, the base invoice lines only store the parent tax in the `account_move_line_account_tax_rel` table. Because of this, if a child tax within the group contains a specific tax report tag, the generic report query would previously fail to pick up those base lines.

This commit updates the SQL join conditions in `l10n_ph_generic_report.py` to also match `account_tax.id` against the child taxes of the linked parent tax using the `account_tax_filiation_rel` table. This ensures that base lines are correctly reported under the tags of their respective child taxes.

Task-6278098

#tax reporting#group taxes#Philippines#accuracy

[FIX] account_accountant: auto apply partner mapping

PR #107314

Enterprise19.0account_accountantMEDIUM

Fixed an issue where partner mapping could be applied automatically on bank statements even when the reconciliation rule was still set to manual. This makes statement handling more consistent and ensures only the right reconciliation rules are suggested to users.

Original PR description

Users may define a reconciliation model for partner mapping by having a matching label and a counterpart item setting only the partner.  If the user then opens the transactions or reconciliation menu and creates a statement, partner mapping will occur automatically, even if the model is still set to 'manual'.

Steps to reproduce:
- Create a reconciliation model with
  - Label: Contains 'mylabel'
  - Counterpart Items: set any partner
- Open accounting app
- From a Bank journal card click 'Transactions'
- Create a statement line containing 'mylabel'

Issue:
Partner will be automatically set according to the reconciliation model, even if it has not been set to 'Automatic'.

opw-5480282

#accounting#bank statements#reconciliation#partner mapping

[FIX] l10n_co_dian: update translations of DIAN email templates

PR #120855

Enterprise19.0l10n_co_dianMEDIUM

This update ensures DIAN email templates in the Colombian localization are translated correctly when a new language is installed. It prevents untranslated invoice and credit note emails for users who add languages after the localization is already in place.

Original PR description

### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly…

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

#localization#translations#email templates#Colombia#DIAN

[FIX] l10n_de: Update the default cash discount accounts

PR #121854

Enterprise19.0l10n_de_reportsMEDIUM

The default cash discount account codes in the German SKR03 template were incorrect and have been updated. This helps ensure accounting exports and postings use the right accounts, reducing the risk of reporting errors.

Original PR description

The default cash discount accounts referenced in the 
German skr03 template used the wrong account codes. 
The template has been updated with the right ones.

task-4915939
opw-4909059

Forward-Port-Of: odoo/enterprise#121692
Forward-Port-Of: odoo/enterprise#121180

#accounting#germany#tax#csv export

[FIX] ai: ensure the arg "fields" is always the expected list type

PR #120799

Enterprise19.0aiMEDIUM

This change fixes an issue that could stop AI-assisted field population from working in Studio forms. It ensures the system receives the field information in the expected format, preventing the error and allowing users to complete the action successfully.

Original PR description

**STEPS TO REPRODUCE**
1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other)
2. Add `employee_feedback` to the prompt using '/'
3. Click the AI button to populate the field
4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'`

**CAUSE**
In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations.

opw-5954203

#ai#studio#form#error#employee appraisal

[FIX] planning: drop extra minute on 24/7 shifts

PR #120219

Enterprise19.0planningMEDIUM

This update fixes a timing issue that could add an extra minute to shifts planned on round-the-clock schedules. As a result, allocated time now matches the intended shift length, improving the accuracy of planning reports and employee schedules.

Original PR description

**Problem:** On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift…

**Problem:**
On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01.

**Steps to reproduce:**
1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day").
2. Assign an employee to that schedule.
3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days).
4. Plan a shift for that employee using the template.
5. Observe the Allocated Time shows one minute more than expected (08:01).

**Current behavior:**
Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports.

**Expected behavior:**
Allocated Time matches the template duration exactly (08:00).

**Cause of the issue:**
In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01.

**Fix:**
Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift.

opw-6265238

#planning#shift scheduling#allocated time#reports

[FIX] l10n_lu{,reports}: fix account type 142 and simplify BS line 319

PR #121891

Enterprise19.0l10n_lu_reportsMEDIUM

This update corrects how the current year’s earnings are classified and makes the Luxembourg balance sheet report calculate the carried-forward result more simply. It helps ensure the report shows the right figures for year-end financial statements.

Original PR description

This commit addresses the account type for the current year earnings and simplifies the calculation for the "Result brought forward" line in the Luxembourg balance sheet reports.

Modifications:
* Changed the account type of account 142 ("Result for the financial year") from `equity_unaffected` to standard `equity`.
* Simplified the formula for the Balance Sheet line "Profit or loss brought forward" (codes `LU_BS_319` and `LU_BSABR_319`).
* The new formula simply targets the `14` accounts while explicitly excluding `142`.

Community PR: odoo/odoo#272362

Ticket [link](https://www.odoo.com/odoo/project.task/6059571)
opw-6059571

#luxembourg#balance-sheet#accounting-report#financial-statements

[FIX] databases: synchronize databases access error

PR #121589

Enterprise19.0databasesMEDIUM

This change fixes an access error that could block database owners from synchronizing their databases. By applying the correct permissions check earlier in the process, the synchronization flow now continues without interruption.

Original PR description

The aim of this commit is to allow the databases_user to synchronize their databases.

Context:
The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights.

Before this commit:
The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model.
As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error.

After this commit:
The flow continues smoothly.
As the action has now a group set on it, this is checked first and match the proper access right.

opw-6329058

#access rights#synchronization#database#permissions

When using group taxes, the base invoice lines only store the parent tax in the `account_move_line_account_tax_rel` table. Because of this, if a child tax within the group contains a specific tax report tag, the generic report query would previously fail to pick up those base lines. This commit updates the SQL join conditions in `l10n_ph_generic_report.py` to also match `account_tax.id` against the child taxes of the linked parent tax using the `account_tax_filiation_rel` table. This ensures that base lines are correctly reported under the tags of their respective child taxes. Task-6278098

Users may define a reconciliation model for partner mapping by having a matching label and a counterpart item setting only the partner. If the user then opens the transactions or reconciliation menu and creates a statement, partner mapping will occur automatically, even if the model is still set to 'manual'. Steps to reproduce: - Create a reconciliation model with - Label: Contains 'mylabel' - Counterpart Items: set any partner - Open accounting app - From a Bank journal card click 'Transactions' - Create a statement line containing 'mylabel' Issue: Partner will be automatically set according to the reconciliation model, even if it has not been set to 'Automatic'. opw-5480282

### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment Only languages installed afterwards are affected ### Cause: The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files The `TranslationImporter` finds nothing to import for them The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed `TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced This is the standard way to push translations while preserving any manually modified values ### Notes: Languages installed before this fix are not updated Only newly installed languages will get the synced translations ### Steps to reproduce: - Install `l10n_co_dian` - Enable Developer Mode in Settings - Install any language (e.g. `fr_FR`) - Go in Settings > Technical > Email > Email Templates - Search for DIAN and open Invoice or Credit Note Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html opw-6269979

The default cash discount accounts referenced in the German skr03 template used the wrong account codes. The template has been updated with the right ones. task-4915939 opw-4909059 Forward-Port-Of: odoo/enterprise#121692 Forward-Port-Of: odoo/enterprise#121180

**STEPS TO REPRODUCE** 1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other) 2. Add `employee_feedback` to the prompt using '/' 3. Click the AI button to populate the field 4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'` **CAUSE** In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations. opw-5954203

**Problem:** On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01. **Steps to reproduce:** 1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day"). 2. Assign an employee to that schedule. 3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days). 4. Plan a shift for that employee using the template. 5. Observe the Allocated Time shows one minute more than expected (08:01). **Current behavior:** Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports. **Expected behavior:** Allocated Time matches the template duration exactly (08:00). **Cause of the issue:** In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01. **Fix:** Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift. opw-6265238

This commit addresses the account type for the current year earnings and simplifies the calculation for the "Result brought forward" line in the Luxembourg balance sheet reports. Modifications: * Changed the account type of account 142 ("Result for the financial year") from `equity_unaffected` to standard `equity`. * Simplified the formula for the Balance Sheet line "Profit or loss brought forward" (codes `LU_BS_319` and `LU_BSABR_319`). * The new formula simply targets the `14` accounts while explicitly excluding `142`. Community PR: odoo/odoo#272362 Ticket [link](https://www.odoo.com/odoo/project.task/6059571) opw-6059571

The aim of this commit is to allow the databases_user to synchronize their databases. Context: The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights. Before this commit: The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model. As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error. After this commit: The flow continues smoothly. As the action has now a group set on it, this is checked first and match the proper access right. opw-6329058