Wednesday, May 13, 2026
36 changes · saas-19.1
Resolved issues and error corrections
This update resolves a problem where the tour worksheet wasn't being saved correctly due to a timing issue. The fix adds a brief delay to ensure the worksheet is fully loaded before saving, preventing random failures. This ensures tour worksheets are reliably saved for users.
Original PR description
Currently, the test tour loads too quickly, so the worksheet is not saved properly. The issue happens because the worksheet is not yet visible on the portal view side. Therefore, i added an extra step to wait for the HTML field to load, giving enough time for the worksheet to be fully loaded. runbot error-242479 Forward-Port-Of: odoo/enterprise#116918
This update clarifies a confusing error message related to multiple GST registrations, making it easier for users to resolve issues. The original error was misleading, leading to unnecessary support requests. The new message directly prompts users to verify the connection between their GST username and number, streamlining the troubleshooting process.
Original PR description
Users operating with multiple GST registrations (GST-wise branches/companies) could encounter a misleading error when the GST username belonged to a different GST number within the same organization. Previously, the system raised an error directly received from the server: [AUTH4041] Invalid Parameter state-cd in request header This message was confusing and led to unnecessary support tickets and false reports, as the issue was actually a mismatch between GST username and number. The error message has been updated to be more explicit and user-friendly: Please confirm that <gst_username> is associated with <gst_number>. Additionally, refactored duplicated logic by extracting the common code into a single helper function and reusing it across all occurrences. task-6041510 Forward-Port-Of: odoo/enterprise#111115
This update resolves an issue where rapid actions triggered duplicate account return check records being created in the database. The fix prevents multiple simultaneous processes from attempting to create the same record, ensuring data integrity and preventing unnecessary database load. This improves system performance and stability.
Original PR description
Issue -------------- When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to…
Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.
steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing
When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.
Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999). Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.
Logs to demonstrate the thread execution:
--------
```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
THREAD NAME: odoo.service.http.request.137360481711808 Thread ID: 137360481711808
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360481711808 -------------DATA PREPARING STAGE------------
Thread ID: 137360481711808
Thread ID: 137360481711808 RECORD EXISTING CHECK: None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
THREAD NAME: odoo.service.http.request.137360513177280 Thread ID: 137360513177280
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360513177280 -------------DATA PREPARING STAGE------------
Thread ID: 137360513177280
Thread ID: 137360513177280 RECORD EXISTING CHECK: None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
Thread ID: 137360481711808 DATA to_create: 168
Thread ID: 137360481711808 done process create
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
Thread ID: 137360513177280 DATA to_create: 168
Thread ID: 137360513177280 done process create
```
- OPW: 5917459
Forward-Port-Of: odoo/enterprise#114045This update enhances the logging of technical errors related to Saudi VAT (ZATCA) compliance within the Odoo system. Previously, these errors were hidden from users to maintain a clean interface, but this made troubleshooting difficult. Now, server logs will record these errors with a specific prefix, allowing our team to quickly identify and resolve issues.
Original PR description
Log suppressed technical validation failures in server logs with a stable ZATCA_ERROR prefix while keeping user-facing errors unchanged. task-6110313 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261536
This fix resolves an issue where generating closing entries in the Inventory Valuation view incorrectly calculated values when multiple companies were selected. The update ensures that the generated account move lines accurately reflect the inventory valuation based on the selected main company, preventing incorrect balances.
Original PR description
**Problem:** In view Inventory valuation, generate entry doesn't work when multiple companies are selected. In the view only the main company matters. That means that even if multiple companies are…
**Problem:** In view Inventory valuation, generate entry doesn't work when multiple companies are selected. In the view only the main company matters. That means that even if multiple companies are selected, only the stock variation lines related to the main company selected are displayed (which is expected). But if you then click on 'generate entry' the account move lines created will have wrong values (not matching the values appearing in the view) **Steps to reproduce:** - create 2 new companies (to have clean accounting) - create a warehouse for both companies - for both comp, in settings for the 'fiscal localization' set Package : Generic Chart of account, if not already set (to have account journals). From company 1 : - create a storable prod with avco perpetual category - confirm PO for 2 @ 10, receive - bill only 1 @ 10 From company 2: - make sure the category is also perpetual average from this other company - confirm PO for 2 @ 50, receive, don't bill Notice how from the 'Inventory Valuation' view, rightfully, only the main company matters (no matter what other comp are selected): - If main comp is comp 1 there is stock variation lines for amount of 10 (which is expected because we have 20 in stock and only 10 in stock valuation account) - If main comp is comp 2 there is stock variation lines for amount of 100 (which is expected because we have 100 in stock and only 0 in stock valuation account) With comp 1 and 2 selected and comp 1 as main company: - click on 'Generate Entry' **Current behavior:** - both line have a balance of 110 **Expected behavior:** - they should have a balance of 10 as we saw on the 'inventory valuation' view **Cause of the issue:** To generate the data from the 'inventory valuation' view, inside _get_report_data() we call stock_value() and stock_accounting_value() to compare values from inventory and value from accounting. https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L36-L37 stock_value() sums total_value() of each product in the valued accounts https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L90-L94 Whereas stock_acounting_value(), sums the balance of each account move line of each valuation account https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L112-L114 All of this is related to the main company because we call _get_report_data() with context 'allowed_company_ids' set to only the main company https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/report/stock_valuation_report.py#L13 But when we click on generate entry, _get_stock_valuation_account_vals() is called with no context modification to 'allowed_company_ids' so when we call stock_value(), https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L238-L239 total_value will be based on both company https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L92 Note that stock_accounting_value() is still rightfully based only on main company because we use self.id in the domain https://github.com/odoo/odoo/blob/dd84309df7fd39e9e97ed02d135d25b211085135/addons/stock_account/models/res_company.py#L105-L108 opw-6168699 Forward-Port-Of: odoo/odoo#262776
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The change ensures that all new batches are assigned the correct, predictable naming scheme, improving batch identification and reporting. This resolves a minor inconsistency in the system.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320
Forward-Port-Of: odoo/enterprise#115809This update fixes a visual issue where the background color of translation spans wasn't consistently displayed on website tabs. The change utilizes a new resource to ensure that all tab descriptions accurately reflect the translation state, improving the overall user experience. This resolves a previously known issue.
Original PR description
Span elements which have a style that causes them to be displayed as "block" do not have the background color given by the translation span (this is a ["known" issue]) To show the translation state on those nodes, this commit uses the resource `force_background_translation_state_selectors` for the following: - `.o_nav_tabs_description`, the description of tabs in `s_tabs_images` Introduction of `force_background_translation_state_selectors`: cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 ["known" issue]: https://github.com/odoo/odoo/commit/9addf9617830885532c27abb0ad5fa915e9f8f62 task-5892636 Forward-Port-Of: odoo/odoo#263620
This update fixes a display issue where the number of ECOs listed on a Bill of Materials (BoM) was incorrect. The fix ensures that the count accurately reflects the ECOs directly associated with the current BoM version, resolving a visual discrepancy and improving data accuracy. This impacts users reviewing BoM details and associated ECOs.
Original PR description
Steps to Reproduce (Fresh Database): -------------------------------------- 1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules 2. Create a product > New -- Name: "Test Product" > Save 3.…
Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
- Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
- Add component: any
4. Create and apply ECO 1 on BoM v1
- Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
- BoM: Test Product (v1) > Confirm > Apply Changes
- This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
- Same as step 4 but select BoM v2
- This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
- Go to Manufacturing > Bills of Materials > New
- Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
- Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
- BoM: select the separate BoM from step 6 > Confirm
Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)
Explain:-
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.
Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.
Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />
```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
('bom_id',
'in',
[710,
1991,
2049,
1913,
1840,
1823,
1676,
1759,
1794,
1651,
1604,
1544,
1537,
1527,
1506,
1460,
1265,
1259,
1196,
1221,
1223,
1060,
1029,
960,
858,
850,
791,
739,
723,
698]),
('type', '=', 'bom')]
```
With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />
```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
1991: set(),
2049: set(),
1913: set(),
1840: set(),
1823: set(),
1676: set(),
1759: set(),
1794: set(),
1651: set(),
1604: set(),
1544: set(),
1537: set(),
1527: set(),
1506: set(),
1460: set(),
1265: set(),
1259: set(),
1196: set(),
1221: set(),
1223: set(),
1060: set(),
1029: set(),
960: set(),
858: set(),
850: set(),
791: set(),
739: set(),
723: set(),
698: {710}}
In [18]: relevant_bom_ids = [
...: bom_id
...: for bom_id, current_bom_set in previous_boms_mapping.items()
...: if labo.id in current_bom_set
...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```
Task-6065020
Forward-Port-Of: odoo/enterprise#114039This update corrects a previous oversight by adding the 'l10n_pl_bank_verification' module to the project's translation files (weblate.json). This ensures that all user-facing text related to this new bank verification feature is correctly translated and available in Polish. This resolves a potential issue with inconsistent translations.
Original PR description
[FIX] Add l10n_pl_bank_verification to weblate.json In a previous PR, we added the new module 'l10n_pl_bank_verification' but didn't added it in weblate.json. This PR fix it See odoo/odoo#262518 Forward-Port-Of: odoo/odoo#263758
This update resolves a technical bug that prevented the system from correctly identifying project documents when a project lacked a designated folder. The fix ensures the system functions smoothly regardless of whether a project has a linked folder, improving document retrieval reliability. This change impacts how projects are associated with their documents.
Original PR description
The `_compute_documents()` method was expecting that the `documents_folder_id` field was always set.
However, the field is not required and can be empty.
This is not an issue if the compute is called on a single record, but when called on a recordset with :
- A project with related folder with at least one document
- A project with `documents_folder_id` empty The compute will fail because it calls `startswith()` with a parameter that is `False`.
```python
File "/home/odoo/src/enterprise/19.0/documents_project/models/project_project.py", line 50, in <lambda>
document_ids = documents.filtered(lambda doc: doc.parent_path.startswith(project.documents_folder_id.parent_path))
TypeError: startswith first arg must be str or a tuple of str, not bool
```
Solution:
Check for project-related documents only if the dedicated folder is set.
Forward-Port-Of: odoo/enterprise#117066This update resolves an issue where the Point of Sale (POS) wouldn't open correctly when reloading in offline mode. The fix ensures data is properly handled during offline reloads, and updated tests confirm the POS can now be reloaded successfully while offline. This improves the user experience and reliability of the POS system.
Original PR description
Currently when reloading the POS while offline the POS does not open despite all data being stored in IndexedDB. This is because some of the data fetching functions were not properly handling the offline case. Modified tests to ensure that the POS can be reloaded while offline. Also modified the tour offline_util so it handles page refresh. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260590
This update fixes a layout issue on the shop grid for users viewing the website in RTL (Right-to-Left) languages. The changes adjust borders and padding to ensure the shop layout appears correctly, providing a better user experience for a wider range of customers. This ensures consistent and accurate product display for all users.
Original PR description
Prior to this commit, the shop grid layout was broken in RTL due to misplaced left borders and padding. This commit adjusts those elements for RTL, fixing the layout. task-5933289 | Before | After | |--------|--------| | <img width="1406" height="869" alt="Screenshot 2026-05-04 at 10 37 56" src="https://github.com/user-attachments/assets/81f057cc-89d3-44f6-a723-9b439b88290d" /> | <img width="1392" height="877" alt="Screenshot 2026-05-04 at 10 36 53" src="https://github.com/user-attachments/assets/ded4eb4a-c82d-4114-ade6-5455f341a8f5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262483
This update resolves an issue where the cursor would incorrectly appear after an image block after deleting content. The fix prevents the system from misinterpreting self-closing elements, ensuring the cursor remains before the image as intended. This improves the user experience when editing content with images.
Original PR description
After a deletion, if the selection would end up on an image and the image is considered as a block, the selection is set inside it. Upon collapse, this leads to having the selection after the image. This commit avoids this by preventing `normalizeEnterBlock` from taking self closing elements into account. Steps to reproduce: - Go to website - Drop a `s_text_image` snippet - Select the image - Press the left cursor key to put the cursor before the image - Type a letter - Press backspace - Type a letter => The second letter was put after the image task-5436148 Forward-Port-Of: odoo/odoo#263543
This update fixes a bug that occurred when users tried to reschedule marketing activities within a campaign. The change prevents errors related to activity hierarchy updates, ensuring campaigns run smoothly and reliably. It also simplifies the process to avoid user mistakes when testing campaigns.
Original PR description
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the…
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the activities to occur some number of days after the other activity and save - Modify the child activity by changing the number of days after its parent that it should run and save - An error will be thrown **Issue:** The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line: `base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date` **Fix:** Prevent the activity hierarchy to be modified on started campaigns. We also change the indexing to avoid further out of range issue and properly default on the participant create value. Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could impact the behavior between test and actual executions. opw-5362978 Forward-Port-Of: odoo/enterprise#107556
This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the user experience and overall presentation.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#117000 Forward-Port-Of: odoo/enterprise#116382
This update resolves an issue where file boxes, even when fully selected and deleted, weren't removed from the To-Do creation screen. The fix allows deletion of non-editable file boxes if their parent is editable, ensuring a cleaner user experience. This improves the overall usability of the HTML editor.
Original PR description
Problem: When adding a file box, selecting all content, and deleting, the file box is not removed. Cause: `o_file_box` is non-editable, so `canBeDeleted` returns `false` for this node, preventing its deletion. Solution: Allow deletion of non-editable nodes when they are fully selected and their parent is editable. Steps to reproduce: - Go to To-Do → Create New. - Upload a file. - Type some text next to the file. - Select all content (Ctrl + A or with the mouse). - Press Backspace/Delete multiple times. - Observe that the file box is not removed. task-6185206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263008
A recent bug in the Odoo sale_expense module prevented users from correctly searching for customers when adding expenses. This fix corrects a technical error related to how domain expressions were used, ensuring the search function now works as intended. This resolves a potential issue where users couldn't accurately record expenses.
Original PR description
**PROBLEM** & operator must be used with 2 Domain. https://github.com/odoo/odoo/pull/206894 forget to convert the right side part to a domain, leading to a traceback. 1. Install sale and expense_sale. 2. Set the Sales/Sales permission to "User: Own Documents only". 3. Create an expense of type communication. 4. On the field "costumer to reinvoice", start typing to search. 5. A traceback will occur. opw-612755 Forward-Port-Of: odoo/odoo#263861
This update corrects a bug in the payroll calculation for Colorado-based employees. Previously, the system incorrectly generated a positive CO State Income Tax amount. This fix aligns with established payroll tax rules, ensuring accurate withholding and preventing potential refund issues.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#116653
Forward-Port-Of: odoo/enterprise#112724This update ensures that PDF attachments sent through the portal chatter are now correctly displayed as previews. Previously, the system was missing key data needed to render these previews. This fix improves the user experience by allowing users to quickly view attached documents directly within the portal.
Original PR description
Before this commit, previews of pdf attachments (introduced in [1]) would not be displayed in portal chatters. This happens due to `_portal_message_format` not returning the data necessary to display pdf previews (i.e. `has_thumbnail` and `thumbnail_access_token`). This commit fixes the issue by returning said data. [1] https://github.com/odoo/odoo/pull/221006 task-6204747 Forward-Port-Of: odoo/odoo#263481
This update clarifies the extra pricing applied when customers select combo items in the self-order system. Previously, customers were confused about additional costs, leading to inquiries about 'too much' charges. This change ensures transparent pricing and avoids customer confusion, improving the overall ordering experience.
Original PR description
The display for the extra price during the combo selection was not very clear. The customer were not aware of the additional cost that were applied when choosing some elements that were not included but extra. This led to customer asking cashier if there was a problem because they were paying "too much" when the computation was actually correct but not clear enough. task-id: 6142095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260705
This update resolves an issue where creating two overtime shifts on the same Saturday (ending at midnight) would trigger an error. The fix addresses a timing discrepancy in how overtime start and end times are calculated, preventing the 'Expected singleton' error. This ensures overtime is correctly recorded for employees with overlapping shifts.
Original PR description
__ ## Short functional explanation of the error When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting…
__ ## Short functional explanation of the error When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error: `ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)` ## Reproduction Steps 1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset. 2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours. 3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager. 4. Create an attendance for your Employee on a Saturday, from 12h to 18h. 5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save. Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. ### Expected behavior The Overtime is registered. ### Unexpected behavior An error occurs: `ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)` ## Origin of the issue The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one. Then, we add these values in a list: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged. https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __ opw-6096454 Forward-Port-Of: odoo/enterprise#114147
This update resolves an issue where test emails sent through the Email Marketing app would leave a related attachment visible in the chatter of contact records. The fix ensures that test messages are properly removed from the Chatter, preventing clutter and improving the user experience. This was a bug present in previous versions.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Upload a file in Settings > Attach a file - Click on the test button to send a test mail to any mail - Go to the first contact record - Related attachment appears in the chatter **Issue:** Before 18.2, messages created for testing were ignored by the Chatter as they were empty (and not unlinked). But if an attachment was provided, it was linked to the test message and not deleted afterwards (which means it shows up in the record chatter). **Fix:** Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to False to trigger the `unlink` logic and remove the related attachments at the same time. backport of: https://github.com/odoo/odoo/commit/526b3d73886558315f2435714b2ed82fec313e78 opw-6168632 Forward-Port-Of: odoo/odoo#262152
A bug in our sale stock test was causing it to pass incorrectly. The test was being executed with the wrong user, leading to inaccurate access rights checks. This fix ensures the test uses the correct user, guaranteeing reliable test results and maintaining data integrity.
Original PR description
When running the test, `button_validate()` was called twice in succession. - Once explicitly - Once through `process_cancel_backorder()` The first time it is called though, it's not through the restricted user that we want to test, allowing some access rights checks to run smoothly. The second time it's called with the restricted user, the cache still contains some data that should be no longer accessible, allowing the test to run even though it shouldn't. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264057
This update resolves an issue where regular users were encountering access errors when validating sales orders, particularly those involving inter-company transactions. Previously, users lacked the necessary permissions to check if a sales order partner was another company, leading to validation failures. This fix ensures all sales order deliveries can be properly validated.
Original PR description
When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047
A recent test in the MRP module failed because the user account lacked the necessary permissions to view lot tracking information. This change explicitly grants the required group, ensuring the test now passes and accurately reflects the system's functionality. This resolves a minor issue impacting test stability.
Original PR description
The test uses the stock move line detailed operations form and expects the `lot_id` field to be present in the view. Without demo data, the current user may not belong to the `stock.group_production_lot` group, causing the field to be absent from the rendered form view and the test to fail. Causing: `AssertionError: 'lot_id' was not found in the view` in line: https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/mrp/tests/test_consume_component.py#L477 Grant the lot tracking group explicitly in the test setup. runbot-243588 Forward-Port-Of: odoo/odoo#263759
This update resolves a visual bug where the timesheet project/task dropdown menu was hidden behind the sticky 'Total' footer. The fix adjusts the dropdown's layering to ensure it's always visible when the edit form is open, improving user experience.
Original PR description
**Steps to reproduce:** - Open Timesheets > Assistant menu. - Click a row near the bottom of the "My Timesheets" section to open the edit form. - Open the Project or Task dropdown menu. **Issue:** The dropdown menu is hidden underneath the sticky "Total" footer. This happens because both the edit form and the footer share the same stacking context priority. **Fix:** Update .o_activitywatch_sync_timesheet_edition_form to manage its own stacking context. It now defaults to z-index: 1 to ensure standard scrolling behavior, but jumps to z-index: 3 on hover or focus-within. This ensures that when a user interacts with the form, its dropdowns correctly float above the sticky footer. task-6105369
This update resolves a technical issue that could cause a tour to generate a traceback if it had no defined steps. The fix simply prevents the tour from starting when there are no actions to guide the user. Previously, a workaround was implemented, but this change provides a cleaner and more reliable solution.
Original PR description
This commit is a backport of the PR odoo/262537 which prevents a traceback when a tour has no steps and thus no actions. We just do not start the tour if it has no steps. The reason why it was at first targeting saas-19.3 is because the `option.fromDB` was removed in this version. And on previous versions, it was really rare for this option to be true which prevented the traceback from being seen by users. On top of that, I revert the onHold property which was added to solve the same issue. But we keep the best solution which is to not start the tour if it has no steps. --- Backport of : https://github.com/odoo/odoo/pull/262537 Remove option.fromDB: https://github.com/odoo/odoo/pull/253523/changes#diff-992f9ec16e1b54e31fb4bbb37d3c0c099738282ad66ef33ea2239b15010351f7L166 Revert onHold: https://github.com/odoo/odoo/pull/255094 Forward-Port-Of: odoo/odoo#263781
This update resolves several errors that occurred when Odoo processed NOTI files for Belgian payroll tax declarations. The fix ensures accurate and reliable transmission of payroll data, preventing potential issues with tax reporting and compliance. This improves the stability and accuracy of the Odoo Enterprise system for our Belgian clients.
Original PR description
Forward-Port-Of: odoo/enterprise#116871
This update resolves an issue where test payrun dates were relying on the current year, leading to unreliable salary calculations. The commit now sets a fixed year for test payruns, ensuring accurate verification of payroll computations. This improves the stability and reliability of the HR payroll testing process.
Original PR description
This commit fixes year for the test payrun as relying on today's year is not reliable to verify salary computations. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/237683
This update fixes a bug that caused the Calendar app to crash when users dragged and released events on touch screen devices. Now, dragging and releasing events works smoothly on both touch and mouse devices, improving the user experience for all calendar users.
Original PR description
When using the Calendar app on a touch screen, dragging an event and releasing it would raise a client error. Releasing a dragged event now works smoothly on both mouse and touch devices. task-6124833 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
This update corrects a calculation error in the employee timesheet system. Previously, the system incorrectly applied the standard 40-hour work week even after changing the employee's contract to 38 hours. This fix ensures accurate timesheet hour tracking based on the employee's current contract version.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install Timesheets Module with demo data 2. Create a new Employee with: * Payroll Page > Contract > Start from 1st March * Payroll Page >…
Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with:
* Payroll Page > Contract > Start from 1st March
* Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
* Select a date in a past week (e.g., 14th April)
* Hours: 8 hours
* Select the newly created employee
5. Go to Timesheets > All Timesheets:
* Filter by the new employee
* Navigate to the same past week
* Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
* Click on '+' to create a new contract version
* Set the version date before the timesheet date (e.g., 12th April)
* Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5
Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.
Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.
Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.
opw-6142137
Forward-Port-Of: odoo/odoo#260614This update fixes an issue where the reprint button on preparation printers was only visible on the device that initially sent the order. By moving data to a shared session variable, the reprint button is now consistently available on all devices within the same order session, streamlining order preparation.
Original PR description
When sending an order to a preparation printer, the reprint button was invisible on any device other than the one that originally sent the order. This happened because `lastPrints` was stored in the order's `uiState`, which is local to each device. Moving it to `last_order_preparation_change` — which is shared across devices in the same session — fixes the issue. The reprint button is now visible and functional on all devices sharing the same session. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6196913
This update fixes an issue where a course would remain active even after all orderlines were removed, preventing table release. The fix automatically cleans up empty courses when the last orderline is deleted, ensuring the system functions correctly and tables can be released promptly.
Original PR description
Steps to reproduce: - add a course - add a orderlines - remove orderlines - the course is still there - unable to release table Fix: Call cleanCourses after removeOrderline so empty unfired courses are automatically deleted when the last orderline of a course is removed. Task-6181153 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
This update resolves a crash in the website editor that occurred when an event was set as the homepage. The issue stemmed from a missing match case in the event ID retrieval process. By adding a default return value, the editor now correctly identifies event IDs, ensuring a stable experience for users managing homepage events.
Original PR description
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the…
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage. In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67). **Steps to reproduce bug:** 1. Create an event website 2. Create an event and visit it 3. On the page click Site > Properties 4. Enable `Is Homepage` 5. Return to the homepage of the application and open the editor https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link **Current behavior before PR:** https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link opw-6101680 Forward-Port-Of: odoo/odoo#262886 Forward-Port-Of: odoo/odoo#258502
This update corrects a visual issue on invoices where section line content was misaligned when prices were hidden and country of origin was displayed. The fix ensures that tax and amount information within hidden section lines are correctly positioned, improving invoice presentation. This resolves a discrepancy impacting invoice clarity and accuracy.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/odoo#263499
This update corrects a visual misalignment on invoices when section prices are hidden and the country of origin is displayed. The fix ensures that tax and amount information within section lines are correctly aligned in the invoice PDF, improving invoice presentation and accuracy. This resolves a prior issue impacting customer invoices.
Original PR description
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1.…
The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice Steps to reproduce: 1. Install account_intrastat module 2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan 3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom 4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test" 5. Click on the three dots at the end of the section line and click on Hide Prices 6. Confirm the invoice and print it 7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes) Issue: When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section Solution: Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines` opw-6147929 Forward-Port-Of: odoo/enterprise#115442