Wednesday, September 24, 2025
56 changes · 19.0
Resolved issues and error corrections
The Mexican electronic invoicing flow now handles customer legal names entered with accents when creating invoices from the self-invoicing portal. This prevents avoidable invoice stamping failures when government records store the same names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
Refreshing appointment slots could fail when no resource was selected because the system tried to read an empty value as a number. This fix handles missing resource selections safely, keeping appointment availability and capacity updates working reliably.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144
Fleet manufacturer records now count only active vehicle models, so the displayed totals better reflect currently used data. Users can also filter vehicle models to view archived entries when needed, improving data review without affecting daily workflows.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
Fixes an issue that could block delivery validation when proceeding with products using expiration tracking but missing a removal date. This helps warehouse users complete affected deliveries without encountering an unexpected error.
Original PR description
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`,…
currently an error occur when user proceed except expired delivery. Steps to Reproduce: - Install the `product_expiry` module. - Create a product with the configuration: - In `Track Inventory`, select `By Lots`. - In the `Inventory tab`, check `Expiration Date`. - In the newly created product, click `Lot/Serial Numbers` button, create a new `Lot/Serial Number`, and clear the `Removal Date` of that Lot/Serial Number. - Go back to the newly created product and update the `Quantity On Hand` of the linked `Lot/Serial Number` by clicking `Update`. - Now go to `deliveries` and create a new `delivery` and add the newly created product and `validate` > `Proceed except expired`. `TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'` This error occurs when user proceed except expired delivery, The removal_date of the move line is computed based on the lot's removal date and the move line's expiration date. If the lot does not have a removal date and the move line also does not have an expiration date, then removal_date on the move line is set to False [1], which raises the error here [2] This commit ensures that it only compares with the move line removal_date if it is present. [1]- https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/models/stock_move_line.py#L56 [2]-https://github.com/odoo/odoo/blob/70a7babcc830f72bd069a5bb1504748363e4e848/addons/product_expiry/wizard/confirm_expiry.py#L48 sentry-6864176071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226025
Product images on website sales pages now keep their original quality instead of being compressed to a lower setting. This improves the visual presentation of products, especially where image detail matters for customer confidence and purchasing decisions.
Original PR description
Product image quality was set to 75% not good enough in some cases. So it increased to 100% to keep the original quality of the image. opw-5094063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates automated website test journeys so they correctly wait when a page reloads or redirects. It helps keep Odoo's validation pipeline stable and reduces false failures in website, event booth, and click-and-collect flows.
Original PR description
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a…
\* = website_event_booth_exhibitor, website_event_booth_sale_exhibitor, website_sale_collect **Issue:** 1. Several tours across multiple modules were failing on runbot because some steps triggered a page reload or redirect without using `expectUnloadPage: true`, which caused those steps to fail. 2. In the `webooth_exhibitor_register` tour, the behavior of the last step before calling the `_getSteps` function differs depending on the installed modules: - With only `website_event_booth_exhibitor` installed, the last step does not trigger a page reload. - With `website_event_booth_sale_exhibitor` also installed, the same step triggers a redirect to the checkout page, which caused the tour to fail. **Fix:** 1. Added `expectUnloadPage: true` to steps that trigger a reload/redirect, so the tour now waits for the new page to load before continuing. 2. Updated `_getSteps` in both modules: - Moved the problematic step of the `webooth_exhibitor_register` tour inside `_getSteps`. - In `website_event_booth_sale_exhibitor`, the same step was updated with `expectUnloadPage: true` to correctly handle the checkout redirection during the payment flow. runbot-[231586](https://runbot.odoo.com/odoo/error/231586) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226276
The Accounting reports page no longer crashes when users load more lines in a Follow-Up Report with many invoices. This improves reliability for customers reviewing large partner statements or follow-up details.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes Odoo’s spreadsheet component and fixes several small user-facing issues. Users should see more reliable spreadsheet sorting and cleaner chart and carousel visuals, improving day-to-day reporting and dashboard presentation.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c84edcb45 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) https://github.com/odoo/o-spreadsheet/commit/0e823e20a [FIX] Carousel: the sidepanel cogwheel has a weird look [Task: 5090177](https://www.odoo.com/odoo/2328/tasks/5090177) https://github.com/odoo/o-spreadsheet/commit/b2aec82f2 [FIX] charts: truncate radar chart labels correctly [Task: 5078858](https://www.odoo.com/odoo/2328/tasks/5078858) https://github.com/odoo/o-spreadsheet/commit/b1f21db41 [FIX] carousel: missing color for empty carousel header [Task: 5082459](https://www.odoo.com/odoo/2328/tasks/5082459) https://github.com/odoo/o-spreadsheet/commit/13482eefd [IMP] test: improve `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update prevents crashes for public website visitors using older Safari versions by adding missing browser support needed for translation caching. Visitors on Safari before version 17 should now be able to load pages normally instead of encountering failures at launch.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228120
This update fixes a failing automated test related to Hong Kong payroll accounting after an internal leave-generation method changed. It helps keep payroll quality checks reliable without changing day-to-day user functionality.
Original PR description
Explanation: _generate_leave method is updated in saas-18.1. build_error-229902 Forward-Port-Of: odoo/enterprise#95084
This update removes a fixed year from point of sale settlement tests, preventing failures when dates change over time. It helps keep automated checks stable so future point of sale updates can be validated more reliably.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171 Forward-Port-Of: odoo/enterprise#93166
Invoice PDFs now include both the product name and its description when a product has extra descriptive text. This prevents important product identification from being omitted on customer-facing invoice documents.
Original PR description
When printing an invoice for a product that has a description, only the description appears on the PDF. Commit https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab removed the concatenation of the product name and description in updateLabel (in product_name_and_description in product module). This commit reintroduce the concatenation of the product name and the product description for invoices by overriding updateLabel in product_label_section_and_note_field in account. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4988340) opw-4988340 Forward-Port-Of: odoo/odoo#222589
Odoo now handles printer setup errors more gracefully when the system cannot add a printer, such as on read-only devices or when a printer name is invalid. Instead of stopping the printer interface, the error is logged and printing services can continue running.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227307 Forward-Port-Of: odoo/odoo#227121
Fixes an issue that could block sending certain Colombian customer invoices when a debit-note-related operation type was selected without a linked reference invoice. This prevents an error during the send process and helps users complete DIAN invoice delivery smoothly.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763 Forward-Port-Of: odoo/enterprise#92714
This change stabilizes an accounting test that could fail unpredictably due to ambiguous domestic fiscal position data. It also adds a safeguard to warn about future localization data that could recreate the issue, helping maintain accounting reliability across countries.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226336
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. The system also prevents merging entries from different tickets, helping avoid lost ticket history and reporting errors.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
This update fixes an issue in the Point of Sale order summary caused by relying on an outdated internal method. It helps ensure order information is prepared correctly, reducing the risk of errors during checkout or order handling.
Original PR description
Replace usage of `serialize` (method that was previously removed) by `serializeForORM` in `OrderSummary`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225982 Forward-Port-Of: odoo/odoo#225583
This fixes automated point of sale localization tests so they no longer depend on a hardcoded invoice year. The change helps keep test results stable over time and reduces false failures during maintenance.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224171
This update fixes an internal test issue in accounting reports that could fail when Czech localization was installed. It makes the test adapt to the actual payment reference value, helping keep builds stable without changing user-facing behavior.
Original PR description
test_document_data_for_bank_journal_with_show_payment_option was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which is a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479 Forward-Port-Of: odoo/enterprise#95014
This fixes an inconsistency in Belgian payroll employee records by making the student status field read-only where it is shown on employees. This prevents users from editing a value that is controlled elsewhere, reducing confusion and avoiding data mismatches.
Original PR description
This commit marks `l10n_be_is_student` field as readonly in `hr.employee` model since it is a related field of `hr.version` and it is not editable in `hr.version` and so there is no reason to make in editable in employee model. runbot-error-231303 Forward-Port-Of: odoo/enterprise#95208
This fix ensures employee version records can be updated correctly even when the selected records belong to different employees. It prevents update failures in HR workflows that manage multiple employee histories at once.
Original PR description
Problem: the write method on the version is not working if the versions are coming from multiple employees. This commit fixes the issue by taking care if the versions belong to different employees. task-5085086 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227117
Italian XML invoices marked as TD01 are now kept as the correct document type when imported as vendor bills. This prevents purchase invoices from being mislabeled as TD05, improving compliance accuracy and reducing manual corrections.
Original PR description
**Issue** When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing. **Steps to Reproduce** 1. Install Accounting, l10n_it and l10n_it_edi 2. Go to…
**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.
**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05
**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891
**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.
opw-4931438
Forward-Port-Of: odoo/odoo#219310Employees and managers can now enter a checkout time directly from the Attendance Gantt popup for open attendance records. This fixes a visibility issue that previously blocked manual checkout entry in that view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978 Forward-Port-Of: odoo/enterprise#92726
The display of “Back on X” messages for employees on leave has been made consistent across chat sidebars, member lists, popovers, and conversation areas. This fixes uneven text size, color, spacing, and alert styling so users see a cleaner and more uniform interface.
Original PR description
- size and color of "Back on X" text when someone is on leave was inconsistent on UI. - discuss sidebar item and member list with "Back on X" had too much height `lh-base` => `lh-sm`. - floating text "Back on X" above conversation had old style of alert instead of newer one that is not rounded nor has margin. Before <img width="1917" height="722" alt="Screenshot 2025-09-23 at 18 18 22" src="https://github.com/user-attachments/assets/ffa12430-1ff6-4271-9b11-c818b262888d" /> After <img width="1918" height="724" alt="Screenshot 2025-09-23 at 18 17 02" src="https://github.com/user-attachments/assets/bbf9c529-b1ae-4340-897d-69a121408189" />
Fixed a typo that caused bullet points in an accounting report error message to display with incorrect spacing. This makes lock date warnings easier for users to read when report external values cannot be modified.
Original PR description
[FIX] account_reports: typo in error message typo in generation of error message saying that lock dates are blocking the modification of a report external value See odoo/enterprise#92949 Forward-Port-Of: odoo/enterprise#95175
Pasting tables from sources such as Google Docs now works more reliably in Odoo editors. Tables remain visible and empty cells are prepared correctly, reducing manual cleanup for users creating website or rich-text content.
Original PR description
### Steps to Reproduce: - Go to the website. - Copy a table from Google Docs. - Paste the table into the editor. - Observe that the table is not visible because some required classes are missing. - Notice that there is no base container inside the empty `<td>` elements. ### Description of the issue/feature this PR addresses: - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. ### Desired behavior after PR is merged: - Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227378
The Discuss app no longer flickers when users press Alt to view keyboard shortcuts, creating a steadier experience. Mobile message action controls are also positioned closer to the relevant message, making conversations easier to use on small screens.
Original PR description
When pressing "ALT" to see hotkey, discuss app was flickering. This happens because the size of action list button is inconsistent with the hotkey overlay. This commit simplifies code around style of…
When pressing "ALT" to see hotkey, discuss app was flickering. This happens because the size of action list button is inconsistent with the hotkey overlay. This commit simplifies code around style of action list, so that the height is deduced from padding like any other button in the rest of UI. Padding and spacing has been adjusted to take into account the removal of imposed height, which fixes the flicker issue. Also fixes an issue where the message action "..." in mobile was too far away from message bubble for other people messages. This comes from long press dropdown also putting empty message action for spacing but it doesn't take into account on message alignment. This now puts the action always at the end of message action. Flicker Before  Flicker After  Mobile Before <img width="408" height="498" alt="mobile-before" src="https://github.com/user-attachments/assets/b3af85d8-7ef5-49aa-a62f-81d57f56a560" /> Mobile After <img width="407" height="503" alt="mobile-after" src="https://github.com/user-attachments/assets/0832761c-fc7c-41c5-b04f-3c9df8ae8799" />
This fixes an issue where Ctrl+Backspace behaved differently in Firefox and Safari compared with Chrome when editing empty or boundary paragraphs. Users now get more predictable text editing behavior across supported browsers.
Original PR description
**Current behavior before PR:**
In Firefox or Safari, `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` ends up with `<p>abc []</p>` which is different o/p than Chrome (`<p>abc def[]</p>`).
This happens because Firefox's Selection.modify("extend", "backward|forward", "word") behaves differently than Chrome when the cursor is at the start or end of a block (or in an empty block). This behavior breaks the output when pressing ctrl + backspace.
**Desired behavior after PR:**
This PR ensures that in such case deletion behavior is same across browsers as Chrome. In other words `<p>abc def</p><p>[]<br></p>` => `ctrl + backspace` should be `<p>abc def[]</p>` .
task-5055135
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226040Spreadsheet imports now correctly handle values that look like dates when they belong in text fields, preventing failed imports and confusing error messages. This helps users re-import exported records, such as pricelist rules, without manual cleanup when date-like values appear in names or other text fields.
Original PR description
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date…
*: test_import_export ### Steps to reproduce: - Go to Sales/Prodcuts/Pricelists - Create a new pricelist with a rule with a set Valid Period - Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format - Delete the record and test the import the XLSX file #### Uncaught Promise: > Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array) ### Cause of the Issue: The issue is raised by the error message: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432 which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place. #### Details: Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet). However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632 To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value. This fix has two major issues: 1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421 ### Fix: We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text). Note: this may also require an adjustment in master for the html type. opw-4935423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226807
The Point of Sale now blocks changes to a product when that same product is already in the current order. This helps avoid inconsistent product details in active carts and reduces checkout errors for staff.
Original PR description
- Prevent update of product via POS when the product is already in the current order (to avoid leading to inconcistent data on this product for the current order). task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219209
Automation rule screens now include archived rules by default without carrying that setting into unrelated lookup dialogs. This prevents users from seeing archived records when searching for related records while configuring automated actions.
Original PR description
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the…
**Before** - the active_test context key is part of the main base_automation action (base_automation_act), but this context key stays in the context further, leading to unwanted filtering in i.e. the action_server_ids.resource_ref search view dialog. - Steps to reproduce: - have base_automation installed - create an automation rule targeting the res.users model - add an Update server action targeting the Partner field - in the resource_ref autocomplete, click on Search More... - the search view dialogs displays archived records **After** - we chose to instead have a default filter in the base_automation_act action to include archived records by default. As the context key to activate the default filter starts with 'search_default_', it is already cleared from the context when opening the form view (standard behavior). - when you reproduce the same steps as before, the archived records are no longer displayed in the search view dialog. **Additional Note** This fix requires to upgrade the base_automation module. opw-4886487 Forward-Port-Of: odoo/odoo#225146
This fix prevents automated live chat tests from failing when call sessions are cleaned up too early. It helps keep quality checks stable so live chat changes can be validated more reliably before release.
Original PR description
Since [1], rtc sessions are garbage collected when creating new live chat sessions. Rtc sessions that didn't receive any update during the last minute are considered as inactive. This can interfere with agent assignation tests: operators in a call are not prioritized. If the session is garbage collected, they are not in a call, and tests can fail. fixes runbot-232705 [1]: https://github.com/odoo/odoo/pull/211359 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227963 Forward-Port-Of: odoo/odoo#227648
When a new chat or live chat channel is created, the person who created it is now reliably notified. This fixes a regression that could leave users unaware that their channel had been created, improving communication flow and reducing confusion.
Original PR description
PR #217543 made a fix for the same issue but since PR #217366 the notification in `_subscribe_users_automatically` is no longer sent to groups. So the creator of the channel won't receive any notification for creating the channel. This PR ensures that the bus notification is always sent to the current user when a channel is created by moving the sending from the `_create_channel` method to the `create` method. task-4920218
Opening the purchase product catalog no longer triggers the same product search twice when suggestions are off. This makes the catalog feel smoother for users and reduces flaky automated checks caused by duplicate loading.
Original PR description
Removes double web_search_read on product catalog, which was bad UX and causing tour non determinism. BEFORE: useEffect is trigger on first mount (as well as state changes), causing double load on catalog open (even with suggest OFF) NOW: Remove useEffect removes double load on catalog open if suggest is OFF (other double load issues on filter changes being worked on here odoo/odoo#225721 with other approach). task#4783508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mobile point of sale payment screen now correctly disables the Validate button when no payment method is selected. This helps prevent cashiers from accidentally trying to complete incomplete payments, reducing errors during checkout.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228057 Forward-Port-Of: odoo/odoo#225917
This fix ensures the Validate button on the point of sale payment screen is disabled on mobile when no payment method is selected. It helps prevent accidental or invalid checkout actions and improves consistency between mobile and desktop use.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#95227 Forward-Port-Of: odoo/enterprise#94100
Barcode database lookups now fill in product information only when the field is still empty. This prevents existing eCommerce descriptions from being accidentally replaced, helping businesses keep their online product content intact.
Original PR description
Scenario: - enable "Barcode Database" in general settings - set an eCommerce description on a product - set a barcode in the database on that product (eg. 799439112766) Result: the eCommerce description has been overwritten by the barcode lookup result. Fix: do like other _update_product_by_barcodelookup methods and only update value that are not yet set. Note: also fixes the return of the overridden methods. opw-5061231 Forward-Port-Of: odoo/enterprise#94098
The Belgian POS reports and invoice views no longer show the warning “THIS IS NOT A VALID VAT TICKET.” This prevents confusion because that warning is only intended for POS receipts that are not final VAT tickets.
Original PR description
- Remove the message "THIS IS NOT A VALID VAT TICKET" from the invoices and POS daily reports views. This message is only necessary on POS receipts that are not final TVA tickets. task-id: 5013860 Forward-Port-Of: odoo/enterprise#92287
The Indian reporting document summary is no longer recreated every time a user opens it, preventing accidental loss of existing summary data. The summary card also correctly avoids showing a missing-data label when the document summary already exists.
Original PR description
Issue: - Document summary was regenerated every time the user clicked on the document summary card. - This caused data loss for already existing summaries and unnecessary restart of the process. - 'Missing' tag appeared in document summary even when data was present. - Additionally, record_name was passed in _check_suite_in_gstr1_report, but as a computed field it never worked as intended. Fix: - Adjusted logic so the document summary is generated only when empty. - Subsequent clicks now reuse the existing summary instead of regenerating it. - No missing tag appears if document summary exists. - Replaced record_name with record_model to ensure correct record count and computed record name.
This fixes a crash that could happen when users opened the command search on tasks where a status field had no available choices. The command palette now safely hides the unavailable action, helping Field Service and task users continue their work without interruption.
Original PR description
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks…
**Steps to reproduce:** - Installed industry_fsm (Field Service) module - Navigate the menu Field Service -> Configuration -> Project - Create a new project - Then Navigate the menu My Tasks -> Tasks - Create a new task with the new created project - Then using the keyboard shortcut ctrl + k for command search, an error occurs **Cause:** - When the `stage_id` statusbar had no possible values, `this.getAllItems()` returned an empty array. - The command `isAvailable` unconditionally accessed `this.getAllItems().at(-1).isSelected`, which is undefined, causing a crash.[see](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/statusbar/statusbar_field.js#L147-L148) **Fix** - Add safe check in the command action so it does not attempt to select a non-existent "next" item. **Result** - The command palette no longer crashes when the `stage_id` field has no available items. Instead, the command is simply unavailable. opw-5084130 upg-3130405 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228130 Forward-Port-Of: odoo/odoo#227440
Fixes an issue where the Terms and Conditions block stayed visible on product pages even after being switched off in the website editor. This ensures website managers can reliably control whether that content appears to customers.
Original PR description
**Description** - following this commit: odoo/odoo@bbb2d98d9ab97ce729d59b9858b63daccf5434e2 terms and conditions was explicitly called with t-call, which ignores whether the view is active or not. This caused the block to remain visible even when toggled off in the website editor. The fix ensures that the call to `website_sale.product_terms_and_conditions` is wrapped in `is_view_active(...)`, so the snippet is only rendered when enabled. **Steps to reproduce before the fix:** 1. Go to website → open any product in edit mode. 2. Toggle off the Terms & Conditions option. 3. The block still shows up. **After the fix:** toggling off correctly hides the block. opw-5096452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228084
This fix restores one-time payment options in Swiss payroll and prevents salary attachments from appearing where they should not. It helps payroll teams keep the employee payroll interface accurate and focused on relevant compensation items.
Original PR description
- Reintroduce one time payments - Blacklist salary attachments
Fixes the website editor so hovering over selectable options, such as blog post authors or contact records, previews the change before it is applied. This restores expected preview behavior and makes editing website content more reliable for users.
Original PR description
### [FIX] html_builder, website: pass `isPreviewing` to action with colors With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply` method of actions should receive an argument…
### [FIX] html_builder, website: pass `isPreviewing` to action with colors With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply` method of actions should receive an argument `isPreviewing`. This has not been done for `BuilderColorPicker`. This commit adds the argument `isPreviewing` when calling `apply` in `BuilderColoPicker`. task-4367641 ### [FIX] html_builder, *: make options with BuilderMany2One previewable *: web, website With the initial [website builder refactor], the options based on `BuilderMany2One` were not previewable (they were in the previous builder). This commit brings back that behaviour. To do so it adds props to `SelectMenu` and options to `Navigator` to receive the information needed for the preview Steps to reproduce: - On `/blog`, open website builder - Click on the author of a blog post - In the sidebar, click on "Contact" to open the dropdown - Hover other authors than the current one - Bug: the hovered author is not previewed in the dom (like in was in the previous builder) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641 Forward-Port-Of: odoo/odoo#223369
This update fixes the guided Sign app tour so it no longer fails when users add a signature field or complete the signing step. It also prevents leftover signature fields from earlier tour runs from disrupting future users, making the training/testing experience more reliable.
Original PR description
Fix `sign_tour`. How to reproduce: 1. Go to tours in Odoo 2. Look up sign_tour 3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the…
Fix `sign_tour`.
How to reproduce:
1. Go to tours in Odoo
2. Look up sign_tour
3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the following screen displays )
<img width="780" height="591" alt="image" src="https://github.com/user-attachments/assets/b164c224-0e3e-4dce-97e6-89848263e59e" />
4. tour fails!
---
First commit
The `sign_tour` was failing after the conversion of the `sign.Template` client action to OWL. The standard `drag_and_drop` tour helper can no longer be used for automatic tour testing because the drop target is inside an iframe whose content is managed by PDF.js.
This commit fixes the tour by utilizing the custom helper function, `dragAndDropSignItemAtHeight`, to programmatically simulate the drag and drop action.
---
Second commit
The step "footer.modal-footer button.btn-primary:enabled" assumes that the Signature Dialog opened from its previous step ("Sign It" navigation button).
However, the "Sign It" navigation button does not always open the dialog.
If signing user (res.users) already has "sign_signature" data, the data will be automatically filled in to the Signature input.
Otherwise, the navigation button will open the Signature Dialog.
Luckily, we can see whether user has "sign_signature" data or not by checking if the <input data-item_type='signature'/> node has "data-auto_value" attribute or not.
We now skip the step if data-auto_value is set for signature.
---
Third commit
If `sign.template_sign_tour` has sign request, it means that the template might have a sign item because the `sign_tour` tour adds the Signature sign item to the template. (If user followed the tour)
When we're copying the sign template to trigger the template tour, we should not copy the sign item. User will be guided to add the sign item during the tour.
---
Note:
ci/security needs to be overriden as it was done for https://github.com/odoo/odoo/pull/134793#issuecomment-1711440188
---
opw-4752794
Forward-Port-Of: odoo/enterprise#93601
Forward-Port-Of: odoo/enterprise#91565Date, datetime, and date range fields now correctly apply values provided by the system, even when the value matches the field's original value. This prevents forms from showing a manually typed date when business logic has enforced a specific date, improving data accuracy and user confidence.
Original PR description
This commit allows date (i.e. date, datetime & daterange) fields to apply a value from the props (e.g. coming from an `onchange`), even if that value is the same as the initial one. Before this commit, it was not possible due to the fact that the date service responsible for the reactivity of the field was updating the input in an incorrect order, causing the field to display the 'input' value, and not the one enforced by the props. Task 4978896 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227102 Forward-Port-Of: odoo/odoo#225841
This fix prevents internal formatting text such as “Team Leader” markers from appearing after a salesperson is selected in CRM. Salesperson suggestions can still show helpful labels, while the saved field now displays a clean user name and the dropdown alignment is improved.
Original PR description
When suggesting records, the `Many2XAutocomplete` component relies on the `web_name_search` method to fetch data. This method returns a dictionary with two keys: `display_name` and…
When suggesting records, the `Many2XAutocomplete` component relies on the `web_name_search` method to fetch data. This method returns a dictionary with two keys: `display_name` and `__formatted_display_name`. The latter is used as the label for suggestions, while `display_name` is used when selecting a record or as a fallback if no formatted value is available. In the `many2one_avatar_leader_user` field, the suggestions currently include the `--(Team Leader)--` markup. However, this markup is also shown in the selected record, where it appears as raw text since markups are not rendered in that context. Step to reproduce the issue: 1. Open a lead on CRM 2. Click on the "Salesperson" field 3. Select "Mitchell Admin" 4. Click on the "Salesperson" field 5. Select "Mitchell Admin" => The field displays `Mitchell Admin --(Team Leader)--` TO BE: The field should display `Mitchell Admin` without markup. To fix this, we will update the `_compute_display_name` override on the `res.users` model in CRM so that markups are added only when the `formatted_display_name` context key is set to `True`. Currently, both `display_name` and `__formatted_display_name` are computed through `_compute_display_name`. The difference is that the `web_name_search` method explicitly sets the context key `formatted_display_name` to `True` when computing `__formatted_display_name`. With this commit, the `_compute_display_name` method will add the `--(Team Leader)--` markup only when computing `__formatted_display_name`. The widget `many2one_avatar_leader_user` should then not show any markup when selecting a record from the suggestions. Task-5093192 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue that could prevent users from opening the Inventory Valuation menu when a company did not have a valuation account configured. The report now handles the missing account safely, avoiding an error screen and keeping inventory valuation accessible.
Original PR description
Issue before this commit: ========================= Currently, when opening the Inventory Valuation menu without setting a Valuation Account in the settings, the system raises the error: `Cannot read…
Issue before this commit: ========================= Currently, when opening the Inventory Valuation menu without setting a Valuation Account in the settings, the system raises the error: `Cannot read properties of undefined (reading 'display_name').` Steps to Reproduce: ========================= - Install the account and stock_account modules. - Switch to another company where the default Valuation Account is not set. - Create a warehouse and a product with a cost. - Create and validate a receipt for that product. - Open the Inventory Valuation menu → traceback occurs. Cause of the issue: ========================= In this [PR](https://github.com/odoo/odoo/pull/224479), a new valuation report was added. At the [mentioned line](https://github.com/odoo/odoo/pull/224479/files#diff-8afed36c6f80919b83630d39c78510289ec8fecc632735d26824a84a517a1b7dR60), it's assumes the account always exists and attempts to access display_name directly, leading to the error. With This Commit: ========================= We ensure that display_name is only accessed if the account exists, preventing the traceback.
Czech VAT return entries without a partner VAT number are now placed in section A5 regardless of invoice amount. Entries under special VAT regimes for travel services and margin schemes are also consistently reported in A5, helping businesses produce compliant Czech VAT filings.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787 Forward-Port-Of: odoo/enterprise#92833
The website shop sitemap now avoids a memory-heavy loading behavior when handling very large product catalogs. This helps prevent server crashes caused by search engines or other crawlers requesting the sitemap, improving availability for online stores.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228078 Forward-Port-Of: odoo/odoo#223054
This fixes a display issue in surveys where the progress indicator in the bottom-right corner only showed part of its text. Users filling out surveys will now see the full progress message, making completion status clearer.
Original PR description
Issue: When filling in a survey, the progress in the bottom right of the page does not show progress correctly. Only part of the text appears. Cause: Part of the text is not encompassed by any tag, so they are a loose node. Because this javascript code has migrated to the OWL framework these loose nodes are not rendered directly anymore. Solution: Encapsulate all the text in spans Task-5062196
This fix prevents an error when users open sale order line details with invoice lines from a product form dialog. It keeps the accounting-related view working reliably in customized Studio layouts where the usual search context is not available.
Original PR description
…in a dialog Steps to reproduce ================== Prerequisites: Having a product with an SO and an Invoice confirmed. Steps: - Open Product Variant Form - Open Studio - Add new O2M to SOL: Product (Sale Order Line) - Edit subview form - Add invoice_lines - Quit Studio - Click on SOL on Product view → It crashes => TypeError: can't access property "context", ctx.env.searchModel is undefined Cause of the issue ================== In form view dialogs, we don't have a search model Solution ======== We should use the context from the current record opw-4921186 Forward-Port-Of: odoo/enterprise#95259
Journal entry numbers can no longer be edited directly from the list view once entries are no longer in draft. This helps protect accounting records from accidental changes and keeps posted journal entries consistent.
Original PR description
**Issue** It was possible to edit the journal entry number in the list view even when the entry state was not 'draft'. **Steps to Reproduce** 1. Go to Accounting > Accounting > Journal Entries. 2. Select any journal entry. 3. Double-click on the Journal Number field and attempt to edit it. **Root Cause** The 'name' field in the list view did not have a readonly attribute, allowing inline editing regardless of the journal entry's state. Opw-5009421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226064 Forward-Port-Of: odoo/odoo#224475
A styling file was renamed so it is correctly loaded in the website editor. This restores the intended behavior where section content is hidden while positioning a background image, making the editing experience clearer and less confusing.
Original PR description
__Current behavior before commit:__ [A PR] renamed the `.inside.*` files to `.edit.*`. However [the forward-port] of another PR introduced a new `.inside.*` file (i.e. `background_position_overlay.inside.scss`) but it was merged after the former one. This SCSS file is used to make the content of the section invisible when positioning its background image. But it is currently not included in the asset. __Description of the fix:__ Rename `background_position_overlay.inside.scss` to `background_position_overlay.edit.scss` to include it in `html_builder.assets_inside_builder_iframe` [A PR]: https://github.com/odoo/odoo/pull/224094 [the forward-port]: https://github.com/odoo/odoo/pull/226901 task-5111606
Customers can now change product options on website product pages even when some option combinations are excluded. The unavailable choices still look unavailable, but they no longer block shoppers from switching to another valid variant.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a product with attributes A & B; 2. for attribute A, create values A1 & A2; 3. for attribute B, create values B1 & B2; 4. add an attribute exclusion on A1 for B2; 5. add an attribute exclusion on A2 for B1; 6. open the product's website page. Issue ----- It's impossible to change attributes. Cause ----- Commit bbb2d98d9ab97 prevents selecting impossible combinations, as a consequence, it's impossible change product variants whose attributes exclude each other. Solution -------- Do not add the `disabled` attribute for excluded attributes, but maintaining the visual cues. Suggestion for future [IMP]: disable attributes as they were defined, without also disabling their inverse, e.g. if A1 is selected, disable B2, but don't disable A2 because B1 is selected. opw-5019677 opw-5050472 Forward-Port-Of: odoo/odoo#226612
This update adds test coverage to ensure quantity-based pricelist discounts continue to appear correctly on eCommerce product pages. It helps prevent regressions where shoppers might not see discounted prices when changing quantities.
Original PR description
Manual forward-port of the test added in f9c4001d7df3, to prevent regression of pricelist discounts price not getting displayed in eCommerce. opw-5037669
Sales orders now exclude section and note lines when calculating invoiced amounts. This keeps sales invoice totals aligned with accounting behavior and avoids display-only text affecting business figures.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228146