Odoo Changelog — 2026-09-05

Saturday, September 5, 2026

12 changes · saas-19.1

Bug Fixes(12)

Resolved issues and error corrections

[FIX] l10n_fr_pdp: correct Flow 10 tax data

Coresaas-19.1l10n_fr_pdpMedium

Flow 10 reports now check unsupported tax rates before sending and keep VAT breakdowns aligned with invoice totals. This helps French e-invoicing reports avoid inconsistent tax summaries and preserves exemption details in the generated XML.

Original PR description

Flow 10 reports currently send unsupported custom tax rates without reporting an error on the related journal entry. Untaxed invoice lines also produce a zero taxable amount, which makes the VAT breakdown inconsistent with the invoice total. Exemption reasons without a code are omitted from the XML.

Validate tax rates before sending. Include the base of untaxed lines in the tax summary and preserve exemption reasons so the generated totals and VAT breakdown remain consistent.

No Task id

Forward-Port-Of: odoo/odoo#286547

#France#VAT#e-invoicing#Flow 10

[FIX] l10n_lu_reports: correct investment account mapping

PR #130594

Enterprisesaas-19.1l10n_lu_reportsMedium

The Luxembourg Balance Sheet now places own shares and related undertaking shares in the correct investment categories. This improves the accuracy of statutory financial reports and helps businesses avoid misclassified balances in official filings.

Original PR description

Currently, the Luxembourg Balance Sheet incorrectly maps accounts
`502000` and `503000` under the `III. Investments` section.

**Steps to reproduce:**
- Install the `l10n_lu_reports` module and switch to the `LU Company`.
- Navigate to Accounting > Accounting > Journal Entries and create and
  post two journal entries:
  - One with account `502000 Own shares or own corporate units`.
  - Another with account `503000 Shares in undertakings with which...`.
- Navigate to Reporting > Balance Sheet and check the `III. Investments` section.

**Observation:**
- `502000 (Own shares...)` is wrongly added under `3. Other investments`.
- `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`.

In the generated XML report:
- `502000 (Own shares...)` balance is added inside `<NumericField id="195">`.
- `503000 (Shares in undertakings...)` balance is added inside 
   `<NumericField id="209">`.

**Expected behavior:**
According to the Luxembourg documentation mapping tables [1],
- Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`.
- Account `503000 (Shares in undertakings...)` should be mapped 
  to `<NumericField id="195">`.

**Root Cause:**
At [2], the `account_codes_formula` values are incorrectly assigned:
account code `503` is mapped under `2. Own shares`, while account code
`502` is mapped under `3. Other investments`. This reverses the expected
mapping of the two accounts in the Balance Sheet report.

[1]:
https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables

[2]:
https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348

opw-6275340

Forward-Port-Of: odoo/enterprise#128386

[FIX] account_invoice_extract: no OCR flag transfer on partner merge

PR #130534

Enterprisesaas-19.1account_invoice_extract

Merging a contact created through invoice OCR into an existing contact with the same name no longer triggers a validation error. This prevents interruptions when cleaning up duplicate contacts created during invoice processing.

Original PR description

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/enterprise#129623

[FIX] base: prevent OCR flag transfer on partner merge

PR #286803

Coresaas-19.1base

Merging a contact created from OCR into a regular contact with the same name no longer copies the OCR-created marker. This avoids a validation error during contact merges and lets users consolidate duplicate contacts more reliably.

Original PR description

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when…

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR.

But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint.

Fix:
`is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable.

This prevents the True value from being transferred to the destination, avoiding the unique constraint error.

A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed.

Steps to Reproduce on Runbot:
1. Create 2 contacts with the same exact name and have one created by OCR.
I used a server action to manually set the value of
'is_created_by_ocr' to simplify this process.
2. Select the contacts and merge. In the merge window,
set the non-ORC contact to be the destination contact.
3. Upon confirming merge contacts, the validation error will appear.

Related ticket:
opw-6513607

Forward-Port-Of: odoo/odoo#285150

[FIX] stock: round quantities aggregated across move lines

PR #286832

Coresaas-19.1stock

Delivery slips now show rounded product and packaging quantities when a receipt or delivery is split across multiple stock move lines. This prevents confusing decimal artifacts on printed documents, making quantities clearer for customers and warehouse staff.

Original PR description

**Issue**
When a move has several move lines, the printed quantities are not rounded, causing floating-point arithmetic artifacts to appear on the report.

**Steps to reproduce**
- Create and confirm a PO for 15.6 units of a product.
- On the receipt, change the quantity to 17.8 (this splits it into two stock move lines).
- Validate the receipt and print the delivery slip. -> The ordered quantity on the generated PDF is not rounded (floating-point arithmetic issue).

**Cause**
While printing the delivery slip, quantities are aggregated by product: https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/report/report_deliveryslip.xml#L174

No rounding is performed while subtracting quantities from the ordered quantity (resulting in 13.399..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L927

Nor while adding the second move line's quantity back to the ordered quantity (resulting in 15.599..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L938

**Additional note**
Same issues arise for `packaging_qty_ordered`, `quantity` and `packaging_quantity`.

opw-6469422

Forward-Port-Of: odoo/odoo#283792

[FIX] planning: multi-edit not working with default "Employees" filter

PR #130567

Enterprisesaas-19.1planningMedium

Fixed an issue in Planning where adding the Employees filter by default in the Gantt view could prevent multi-create or multi-edit actions from working. This helps managers reliably schedule multiple shifts even when the default employee-focused view is enabled.

Original PR description

## Step to reproduce:
- Install Planning
- Add "Employees" filter by default to a Gantt

## Result:
The multi-create does not work because isManager does not resolve due to the early [return](https://github.com/odoo/enterprise/blob/0bee2f47c7e9d0b9a8d171fccde398a680a73415/planning/static/src/views/planning_gantt/planning_gantt_model.js#L60-L63)

task-6535800

Forward-Port-Of: odoo/enterprise#130369

#planning#gantt#employees#scheduling

[FIX] website: fix history of `value` property of input field elements

PR #286805

Coresaas-19.1websiteMedium

This fix ensures changes to default values in website form fields are properly reversed when users undo their edits. It also prevents old date values from lingering when switching form field types, making the website builder behave more reliably.

Original PR description

The `value` property of the elements is not tracked by the history plugin, because `MutationObserver` does not produce mutations for that.

This commit uses custom mutations when the `value` is changed, to restore the previous value on undo.

Steps to reproduce:
- Open website builder
- Add a form
- Set a "Default Value" on a text field
- Press enter (to end preview)
- Undo (with the button, or with focus out of the option's input)
- Bug: The value shown in the page did not revert with undo

Similar bug in translate mode

task-6229671

Forward-Port-Of: odoo/odoo#286542
Forward-Port-Of: odoo/odoo#281232

#website builder#forms#undo#translation

[FIX] l10n_in_reports: fix GST token refresh cron

PR #130492

Enterprisesaas-19.1l10n_in_reports

The scheduled GST token refresh now correctly handles cases where multiple companies are processed at the same time. This helps ensure Indian GST reporting integrations continue refreshing on time when at least one company token is successfully updated.

Original PR description

The `_cron_refresh_gst_token` method is called by a cron job. Previously, when scheduling the next cron execution, it checked
`self.company_id.l10n_in_gstr_gst_token`.
However, since the cron can process multiple companies, relying on `self.company_id` could result in incorrect behavior.

In this commit, a flag is introduced to track whether at least one GST token was refreshed successfully. If a token was refreshed, the cron is scheduled to run again after 6 hours.

Forward-Port-Of: odoo/enterprise#130317

#GST#India#scheduled task#token refresh

[FIX] l10n_fr_pdp: correct Flow 10 invoice type codes

PR #286866

Coresaas-19.1l10n_fr_pdpMedium

French PDP Flow 10 now classifies vendor bills and credit notes using the correct document type, preventing purchase invoices from being reported as credit notes. This reduces the risk of electronic invoices being rejected because they appear to reference a missing prior invoice.

Original PR description

Flow 10 used move.is_inbound() to distinguish invoices from credit notes. While this gives the expected result for sales documents, it reverses the codes for purchase documents. Vendor bills were therefore reported as credit notes and could be rejected for having no preceding invoice reference.

Determine the document kind from move_type instead. Regular invoices now use code 380 and credit notes code 381. Self-billed invoices and credit notes use codes 389 and 261 respectively.

No Task id

Forward-Port-Of: odoo/odoo#286526

#France#e-invoicing#PDP#invoices

[FIX] l10n_be_codabox: use last SODA import date to filter the fetch

PR #130183

Enterprisesaas-19.1l10n_be_codaboxMedium

The Belgian Codabox integration now checks the actual last SODA import date when fetching new salary statements. This prevents statements generated earlier in an accounting period from being skipped, helping companies keep payroll accounting imports complete.

Original PR description

Before v19.1, we used to set the date on the journal entry based on the generation date of the SODA statement during the import.

So it was possible to use the last date found in the salary journal as a `date_from` filter when fetching new SODA statements.

Starting from v19.1, we now set the date on the journal entry as the last day of the accounting period referenced in the SODA file. However, we didn't change the fetching logic accordingly.

If a SODA statement is generated on July 7 for the accounting period of July, the date on the journal entry would be July 31 and, consequently, any other SODA statement generated in-between those dates would be filtered out during the fetch.

Ticket: opw-6214589

#Belgium#Codabox#SODA#payroll#accounting

[FIX] account_saft: exclude journal entries with current asset accounts from SAF-T

PR #130566

Enterprisesaas-19.1account_saftMedium

Generating Norwegian SAF-T reports could fail when journal entries used current asset accounts. The fix excludes those entries from the affected SAF-T partner account logic, preventing the report error and restoring reliable export generation.

Original PR description

Currently, an error occurs when generating the SAF-T report for a
journal entries with the `asset_current` account type.

**Steps to reproduce:**
- Install `l10n_no_saft` and `accountant` modules and switch to a NO Company.
- Go to Contacts and set the ZIP code and state, then add a contact for
  the NO Company record.
- Create a new Journal Entry, click `Add a line`, and set an account of
  type `Current Assets` (e.g., `1000 Development, acquired`) with the
  partner set to the NO Company.
- Navigate to Reporting > General Ledger.
- Click the gear icon and select `SAF-T`.

**Error:**
`KeyError: 'accounts'`

**Root Cause:**
At [1], from `19.0`, `asset_current` was mistakenly included in the 
second-to-last account type condition of the domain. As a result, 
partners linked to `asset_current` accounts are included in the
`customer_vals_list` at [2].

However, `_l10n_no_saft_get_partners_accounts()` at [3] does 
not retrieve accounts of type `asset_current`. Therefore, when 
the `if` condition is not satisfied, the `accounts` key is not added 
to `partner_vals`.

Since the partner has already been added to `customer_vals_list` at [2],
the SAF-T template at [4] later tries to access `partner_vals['accounts']` 
when generating the `BalanceAccount` nodes, resulting in the error.

**Fix:**
This commit prevents the error by removing `asset_current` from 
the domain, similar to previous versions.

[1]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L307-L313

[2]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L356-L362

[3]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/models/account_general_ledger.py#L37-L42

[4]:
https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/data/saft_report.xml#L27-L37

opw-6441743

Forward-Port-Of: odoo/enterprise#127744

[FIX] sale_stock_renting: only show stock qty in the schedule rows

PR #130513

Enterprisesaas-19.1sale_stock_renting

Rental order lines created from the Rental Schedule now keep clean product names, such as "Bike", instead of incorrectly including stock quantities. Stock quantities remain visible only in the schedule rows where they help planning, reducing confusion on customer-facing order details.

Original PR description

Versions -------- 19.0 and later Steps ----- - Install `sale_stock_renting`. - Go to Rental > Orders > Rental Schedule. - Create a new rental order line from a cell of the gantt view, on a row…

Versions
--------
19.0 and later

Steps
-----
- Install `sale_stock_renting`.
- Go to Rental > Orders > Rental Schedule.
- Create a new rental order line from a cell of the gantt view, on a row grouped by a storable rentable product.

Issue
-----
The first line of the description of the created line is named "Bike (3 items)" instead of "Bike".

Cause
-----
The `display_name` override adding that quantity is keyed on the `in_rental_schedule` context key. That key is set on the `action_rental_order_schedule` action itself, so it is part of the search context and is propagated to every record, dialog and dropdown opened from the schedule, while it is only meant to flag that we are in the schedule (default values conversion, hidden onchange buttons, group expansion, ...).

Solution
--------
Introduce a dedicated `display_renting_stock_quantity` context key and depend on it instead when fetching data to build the gantt rows, leaving the records opened from the schedule with their regular display name.

Forward-Port-Of: odoo/enterprise#130322

Flow 10 reports currently send unsupported custom tax rates without reporting an error on the related journal entry. Untaxed invoice lines also produce a zero taxable amount, which makes the VAT breakdown inconsistent with the invoice total. Exemption reasons without a code are omitted from the XML. Validate tax rates before sending. Include the base of untaxed lines in the tax summary and preserve exemption reasons so the generated totals and VAT breakdown remain consistent. No Task id Forward-Port-Of: odoo/odoo#286547

Currently, the Luxembourg Balance Sheet incorrectly maps accounts `502000` and `503000` under the `III. Investments` section. **Steps to reproduce:** - Install the `l10n_lu_reports` module and switch to the `LU Company`. - Navigate to Accounting > Accounting > Journal Entries and create and post two journal entries: - One with account `502000 Own shares or own corporate units`. - Another with account `503000 Shares in undertakings with which...`. - Navigate to Reporting > Balance Sheet and check the `III. Investments` section. **Observation:** - `502000 (Own shares...)` is wrongly added under `3. Other investments`. - `503000 (Shares in undertakings...)` is wrongly added under `2. Own shares`. In the generated XML report: - `502000 (Own shares...)` balance is added inside `<NumericField id="195">`. - `503000 (Shares in undertakings...)` balance is added inside `<NumericField id="209">`. **Expected behavior:** According to the Luxembourg documentation mapping tables [1], - Account `502000 (Own shares...)` should be mapped to `<NumericField id="209">`. - Account `503000 (Shares in undertakings...)` should be mapped to `<NumericField id="195">`. **Root Cause:** At [2], the `account_codes_formula` values are incorrectly assigned: account code `503` is mapped under `2. Own shares`, while account code `502` is mapped under `3. Other investments`. This reverses the expected mapping of the two accounts in the Balance Sheet report. [1]: https://ecdf.b2g.etat.lu/ecdf/pcnMappingTables [2]: https://github.com/odoo/enterprise/blob/29c186827f0171292f1243e0deb8fe040c027a89/l10n_lu_reports/data/account_financial_html_report_bs.xml#L335-L348 opw-6275340 Forward-Port-Of: odoo/enterprise#128386

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: is_created_by_ocr should have copy=False and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/enterprise#129623

`is_created_by_ocr` identifies partners that were automatically created while processing an OCR document. A constraint prevents multiple partners with the same name to be created by OCR. But, when merging an OCR-created partner into a regular partner with the same name, the merge copies `is_created_by_ocr` to the destination before deleting the source partner. This temporarily leaves two active OCR partners with the same name and raises the unique constraint. Fix: `is_created_by_ocr` should have `copy=False` and should not be transferred when merging. Make the merge skip fields that are not copyable. This prevents the True value from being transferred to the destination, avoiding the unique constraint error. A test has been added in `account_invoice_extract` in enterprise, since `is_created_by_ocr` is only added to `res.partner` when that module is installed. Steps to Reproduce on Runbot: 1. Create 2 contacts with the same exact name and have one created by OCR. I used a server action to manually set the value of 'is_created_by_ocr' to simplify this process. 2. Select the contacts and merge. In the merge window, set the non-ORC contact to be the destination contact. 3. Upon confirming merge contacts, the validation error will appear. Related ticket: opw-6513607 Forward-Port-Of: odoo/odoo#285150

**Issue** When a move has several move lines, the printed quantities are not rounded, causing floating-point arithmetic artifacts to appear on the report. **Steps to reproduce** - Create and confirm a PO for 15.6 units of a product. - On the receipt, change the quantity to 17.8 (this splits it into two stock move lines). - Validate the receipt and print the delivery slip. -> The ordered quantity on the generated PDF is not rounded (floating-point arithmetic issue). **Cause** While printing the delivery slip, quantities are aggregated by product: https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/report/report_deliveryslip.xml#L174 No rounding is performed while subtracting quantities from the ordered quantity (resulting in 13.399..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L927 Nor while adding the second move line's quantity back to the ordered quantity (resulting in 15.599..): https://github.com/odoo/odoo/blob/189df3538aa07d22f683008522b9143421f411a2/addons/stock/models/stock_move_line.py#L938 **Additional note** Same issues arise for `packaging_qty_ordered`, `quantity` and `packaging_quantity`. opw-6469422 Forward-Port-Of: odoo/odoo#283792

## Step to reproduce: - Install Planning - Add "Employees" filter by default to a Gantt ## Result: The multi-create does not work because isManager does not resolve due to the early [return](https://github.com/odoo/enterprise/blob/0bee2f47c7e9d0b9a8d171fccde398a680a73415/planning/static/src/views/planning_gantt/planning_gantt_model.js#L60-L63) task-6535800 Forward-Port-Of: odoo/enterprise#130369

The `value` property of the elements is not tracked by the history plugin, because `MutationObserver` does not produce mutations for that. This commit uses custom mutations when the `value` is changed, to restore the previous value on undo. Steps to reproduce: - Open website builder - Add a form - Set a "Default Value" on a text field - Press enter (to end preview) - Undo (with the button, or with focus out of the option's input) - Bug: The value shown in the page did not revert with undo Similar bug in translate mode task-6229671 Forward-Port-Of: odoo/odoo#286542 Forward-Port-Of: odoo/odoo#281232

The `_cron_refresh_gst_token` method is called by a cron job. Previously, when scheduling the next cron execution, it checked `self.company_id.l10n_in_gstr_gst_token`. However, since the cron can process multiple companies, relying on `self.company_id` could result in incorrect behavior. In this commit, a flag is introduced to track whether at least one GST token was refreshed successfully. If a token was refreshed, the cron is scheduled to run again after 6 hours. Forward-Port-Of: odoo/enterprise#130317

Flow 10 used move.is_inbound() to distinguish invoices from credit notes. While this gives the expected result for sales documents, it reverses the codes for purchase documents. Vendor bills were therefore reported as credit notes and could be rejected for having no preceding invoice reference. Determine the document kind from move_type instead. Regular invoices now use code 380 and credit notes code 381. Self-billed invoices and credit notes use codes 389 and 261 respectively. No Task id Forward-Port-Of: odoo/odoo#286526

Before v19.1, we used to set the date on the journal entry based on the generation date of the SODA statement during the import. So it was possible to use the last date found in the salary journal as a `date_from` filter when fetching new SODA statements. Starting from v19.1, we now set the date on the journal entry as the last day of the accounting period referenced in the SODA file. However, we didn't change the fetching logic accordingly. If a SODA statement is generated on July 7 for the accounting period of July, the date on the journal entry would be July 31 and, consequently, any other SODA statement generated in-between those dates would be filtered out during the fetch. Ticket: opw-6214589

Currently, an error occurs when generating the SAF-T report for a journal entries with the `asset_current` account type. **Steps to reproduce:** - Install `l10n_no_saft` and `accountant` modules and switch to a NO Company. - Go to Contacts and set the ZIP code and state, then add a contact for the NO Company record. - Create a new Journal Entry, click `Add a line`, and set an account of type `Current Assets` (e.g., `1000 Development, acquired`) with the partner set to the NO Company. - Navigate to Reporting > General Ledger. - Click the gear icon and select `SAF-T`. **Error:** `KeyError: 'accounts'` **Root Cause:** At [1], from `19.0`, `asset_current` was mistakenly included in the second-to-last account type condition of the domain. As a result, partners linked to `asset_current` accounts are included in the `customer_vals_list` at [2]. However, `_l10n_no_saft_get_partners_accounts()` at [3] does not retrieve accounts of type `asset_current`. Therefore, when the `if` condition is not satisfied, the `accounts` key is not added to `partner_vals`. Since the partner has already been added to `customer_vals_list` at [2], the SAF-T template at [4] later tries to access `partner_vals['accounts']` when generating the `BalanceAccount` nodes, resulting in the error. **Fix:** This commit prevents the error by removing `asset_current` from the domain, similar to previous versions. [1]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L307-L313 [2]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/account_saft/models/account_general_ledger.py#L356-L362 [3]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/models/account_general_ledger.py#L37-L42 [4]: https://github.com/odoo/enterprise/blob/1d49c3731ece1549a7a168bb479773ea279322bd/l10n_no_saft/data/saft_report.xml#L27-L37 opw-6441743 Forward-Port-Of: odoo/enterprise#127744

Versions -------- 19.0 and later Steps ----- - Install `sale_stock_renting`. - Go to Rental > Orders > Rental Schedule. - Create a new rental order line from a cell of the gantt view, on a row grouped by a storable rentable product. Issue ----- The first line of the description of the created line is named "Bike (3 items)" instead of "Bike". Cause ----- The `display_name` override adding that quantity is keyed on the `in_rental_schedule` context key. That key is set on the `action_rental_order_schedule` action itself, so it is part of the search context and is propagated to every record, dialog and dropdown opened from the schedule, while it is only meant to flag that we are in the schedule (default values conversion, hidden onchange buttons, group expansion, ...). Solution -------- Introduce a dedicated `display_renting_stock_quantity` context key and depend on it instead when fetching data to build the gantt rows, leaving the records opened from the schedule with their regular display name. Forward-Port-Of: odoo/enterprise#130322