Odoo Changelog — 2025-07-26

Saturday, July 26, 2025

7 changes · saas-18.3

Bug Fixes(7)

Resolved issues and error corrections

[FIX] web: ignore !important % width/height on dragged elements

PR #220565

Coresaas-18.3web

Fixed a display issue where dragged items with certain forced percentage sizing could appear at the wrong size. This improves visual consistency when moving items, including in automation rule kanban views.

Original PR description

This commit fixes an issue in draggable_hook_builder where elements with !important percentage-based width or height styles would be incorrectly sized when dragged. The sizing would be computed relative to the document rather than the style computed by the hook.

To address this, the hook now applies max-width and max-height styles explicitly. This helps enforce correct sizing and prevents !important rules from interfering with the visual consistency of dragged elements.

The issue was first spotted in the actions kanban view present in the automation rules form view.

task-4891808

Forward-Port-Of: odoo/odoo#219246

#drag-and-drop#display#kanban

[FIX] sale_pdf_quote_builder: prevent errors when handling non-PDF files

PR #220678

Coresaas-18.3sale_pdf_quote_builder

Users can now upload a non-PDF product document and choose quote PDF visibility without immediately triggering an error. The system skips PDF-specific processing for non-PDF files and relies on the existing save-time validation, making the product document workflow more stable.

Original PR description

Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the…

Currently an error occurs when user uploads a non-pdf file on product documents.

Steps to replicate:
- Install `sale_management` and go to products.
- Open any product's form view and click on the `Documents` smart button.
- Click new and upload any non-pdf file.
- On the field `Sale : Visible at`, select the value `inside quote pdf` and you will get the error.

Error:
`PdfReadError: EOF marker not found`

The error occurs because at the line [1] the code requires a pdf file, and as we have passed a non-pdf file the error occurs.

[1] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/sale_pdf_form_field.py#L206

There is already a constraint made for this particular thing [2], but the problem is that the error is due the compute [3] (Because constraints are checked at the time of form saving, and compute runs when a field is changed so even before the constraint is checked the error will be triggered).

[2] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L44-L45

[3] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L59-L61

This commit resolves this issue by  skipping the pdf extraction if the file is not a pdf type, because we already have a constraint [2] that will trigger at save.


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

Forward-Port-Of: odoo/odoo#220574
Forward-Port-Of: odoo/odoo#215844

#product documents#quote builder#pdf#upload

[FIX] account_reports: fix "group By" tax reports with analytics

PR #91082

Enterprisesaas-18.3account_reportsMEDIUM

Fixed an issue where tax reports grouped by account and tax could show an incorrect net amount when invoices used the same tax with different analytic distributions. This helps businesses rely on accurate tax reporting when analytic accounting is enabled.

Original PR description

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with a line, add the tax on it and change the analytic distribution
- Do the same for another invoice with another analytic distribution
- Confirm the invoices
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is only the one of the first invoice, the tax amount is correct

### Cause:
The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together.

This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytics. Because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account.

### Solution:
The previous fix was incorrect.

The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python.

The check on `use_in_tax_closing` was missing so we add it.

opw-4766421

Forward-Port-Of: odoo/enterprise#91065
Forward-Port-Of: odoo/enterprise#90936

#tax reports#analytics#invoicing#accounting

[FIX] knowledge: indeterministic error with calendar event's resize

PR #91072

Enterprisesaas-18.3knowledge

This fix makes the automated check for resizing embedded calendar events in Knowledge more reliable. It prevents occasional false failures caused by the resize control disappearing during the test, helping keep release validation stable without changing user-facing behavior.

Original PR description

This commit fixes an indeterministic error in the
knowledge_calendar_command_tour when a calendar view is embedded and an
event is resized. The resize handler is only visible when hovering the
event, which is required to actually be able to resize it.

This commit merges both the "make resizer visible" step and the "resize
the item" step into a single one as those actions should be done in one
go, instead of separate steps (cf. the hovering state is kind of reset
in-between the steps).

Note: this matches the behavior of the CalendarView's unit tests helpers
(`resizeEventToTime()`).

runbot-error-163015

Forward-Port-Of: odoo/enterprise#91012

#calendar#knowledge#testing#stability

[FIX] l10n_ch_hr_payroll_elm_transmission: Fix rate display in printe…

PR #90957

Enterprisesaas-18.3l10n_ch_hr_payroll_elm_transmission

Printed Swiss payslips now show rates in a cleaner format without unnecessary trailing zeros after the decimal separator. This makes payroll documents easier to read and more professional for employees and payroll teams.

Original PR description

…d payslip

In this PR we improve the rate display, which could include a lot of 0's after the coma.

Forward-Port-Of: odoo/enterprise#90892

#payroll#switzerland#payslip#formatting

[FIX] planning: display employe name without employe right

PR #91023

Enterprisesaas-18.3planningMEDIUM

Planning users without Employee app permissions can now open and view role configuration without encountering an access error. This keeps planning administration available to users who have the right Planning permissions, even if they do not manage employee records.

Original PR description

Trying to display the roles in the planning app is not possible if the user doesn't have hr_rights even with full planning rights.

** Step to reproduce **
- Connect to Odoo with an user that only have acces right for "Planning" (no employees).
- Open Planning app
- Configuration>Roles
- It will trigger an Access Error (If it didn't trigger add a user to Ressources)

** Cause of the issue **

The acces for the default_role_id is limited to hr.group_hr_user:
https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L27
But is used in _compute_display_name:
https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L73

** Fix **

Retrieve the information about the role with sudo

opw-4908979

Forward-Port-Of: odoo/enterprise#90243

#planning#roles#access rights

[FIX] account: fix "group By" tax reports with analytics

PR #220684

Coresaas-18.3accountMEDIUM

Fixes an issue where tax reports could show incorrect net amounts when invoices used the same tax with different analytic distributions. This helps ensure grouped tax reports reflect the full taxable base, improving reliability for accounting and reporting.

Original PR description

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with a line, add the tax on it and change the analytic distribution
- Do the same for another invoice with another analytic distribution
- Confirm the invoices
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is only the one of the first invoice, the tax amount is correct

### Cause:
The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together.

This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytic because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account.

### Solution:
The previous fix was incorrect.

The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python.

The check on `use_in_tax_closing` was missing so we add it.

opw-4766421

Forward-Port-Of: odoo/odoo#220662
Forward-Port-Of: odoo/odoo#220394

#tax reports#analytics#invoicing#accounting

This commit fixes an issue in draggable_hook_builder where elements with !important percentage-based width or height styles would be incorrectly sized when dragged. The sizing would be computed relative to the document rather than the style computed by the hook. To address this, the hook now applies max-width and max-height styles explicitly. This helps enforce correct sizing and prevents !important rules from interfering with the visual consistency of dragged elements. The issue was first spotted in the actions kanban view present in the automation rules form view. task-4891808 Forward-Port-Of: odoo/odoo#219246

Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the `Documents` smart button. - Click new and upload any non-pdf file. - On the field `Sale : Visible at`, select the value `inside quote pdf` and you will get the error. Error: `PdfReadError: EOF marker not found` The error occurs because at the line [1] the code requires a pdf file, and as we have passed a non-pdf file the error occurs. [1] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/sale_pdf_form_field.py#L206 There is already a constraint made for this particular thing [2], but the problem is that the error is due the compute [3] (Because constraints are checked at the time of form saving, and compute runs when a field is changed so even before the constraint is checked the error will be triggered). [2] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L44-L45 [3] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L59-L61 This commit resolves this issue by skipping the pdf extraction if the file is not a pdf type, because we already have a constraint [2] that will trigger at save. sentry-6161120972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220574 Forward-Port-Of: odoo/odoo#215844

### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytics. Because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/enterprise#91065 Forward-Port-Of: odoo/enterprise#90936

This commit fixes an indeterministic error in the knowledge_calendar_command_tour when a calendar view is embedded and an event is resized. The resize handler is only visible when hovering the event, which is required to actually be able to resize it. This commit merges both the "make resizer visible" step and the "resize the item" step into a single one as those actions should be done in one go, instead of separate steps (cf. the hovering state is kind of reset in-between the steps). Note: this matches the behavior of the CalendarView's unit tests helpers (`resizeEventToTime()`). runbot-error-163015 Forward-Port-Of: odoo/enterprise#91012

Trying to display the roles in the planning app is not possible if the user doesn't have hr_rights even with full planning rights. ** Step to reproduce ** - Connect to Odoo with an user that only have acces right for "Planning" (no employees). - Open Planning app - Configuration>Roles - It will trigger an Access Error (If it didn't trigger add a user to Ressources) ** Cause of the issue ** The acces for the default_role_id is limited to hr.group_hr_user: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L27 But is used in _compute_display_name: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L73 ** Fix ** Retrieve the information about the role with sudo opw-4908979 Forward-Port-Of: odoo/enterprise#90243

### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytic because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/odoo#220662 Forward-Port-Of: odoo/odoo#220394