### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ccf90d6262 [REL] 19.2.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5883e326cd [FIX] Dynamic pivot: header alignment [Task: 5922279](https://www.odoo.com/odoo/2328/tasks/5922279)
https://github.com/odoo/o-spreadsheet/commit/a714ce64b1 [FIX] chart-panel: reset when changing panel [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109013
Forward-Port-Of: odoo/enterprise#103130

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#109612
Forward-Port-Of: odoo/enterprise#107438

When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views).

Steps to reproduce:
1. Create a bill of materials for a final product
2. Add a consumable component
3. Create an operation without steps
4. Add a by-product tracked by serial number
5. Specify that the by-product is produced in the operation above
6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves"
7. Create a manufacturing order for the BOM and confirm it
8. Open the Shop Floor view from the MO
9. Observe the extra line for the by-product in both overview and work center views

Root cause:
The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button.

Solution:
Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled.

Task-5431295

Forward-Port-Of: odoo/enterprise#109689
Forward-Port-Of: odoo/enterprise#103260

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109510
Forward-Port-Of: odoo/enterprise#105969

When a workspace(folder) linked to a folder setting is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``documents_account`` module
- Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save >
- Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save
- Go to Documents > Click on Workspace A > Actions > Move to trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint
"documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting"
```

solution:
override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings,
preventing their deletion during the garbage collection.

sentry-7193540869

Forward-Port-Of: odoo/enterprise#109636
Forward-Port-Of: odoo/enterprise#104875

## Short functional explanation of the error
When a candidate is refused, an email isn't sent to their email address.

## Reproduction Steps
1. Open Mailhog in a separate tab.
2. Go to the Recruitment app and select any job position.
3. Click on new to create a new application. Enter an applicant name and an applicant email.
4. Check Mailhog: a job application has been sent to the applicant.
5. Go back on the Recruitment app and click on Refuse. In the wizard, make sure you toggle Send Email and click on Refuse.

### Expected behavior
In Mailhog, a refusal mail has been sent to the applicant.

### Unexpected behavior
Nothing is sent.

## Origin of the issue
When refusing a candidate, we create a notification in the chatter but an email isn't sent. This is due to the `incoming_email_to` field, which is checked here:

https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4040-L4053

but because this field is already retrieved here:
https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4025 the last condition will always be true, preventing the recipient's data to be added to the message, thus preventing the message to be sent correctly.

Note: as of 19.0, the field `outgoing_email_to` can be used to determine the recipient's email address.
Note: we remove `'body_is_html': True` because this field
is misused in this case: when set at true, the field is always
considered as HTML
__
opw-5980079

Forward-Port-Of: odoo/odoo#252036

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/c7598b3a3e [REL] 19.1.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/f59db40bd3 [FIX] Dynamic pivot: header alignment [Task: 5922279](https://www.odoo.com/odoo/2328/tasks/5922279)
https://github.com/odoo/o-spreadsheet/commit/1103dcbea7 [FIX] chart-panel: reset when changing panel [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
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: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Forward-Port-Of: odoo/odoo#247995
Forward-Port-Of: odoo/odoo#221189

## Issue:
Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees.

## Steps to reproduce:
1. Connect to Outlook and Sync for user A.
2. Create a recurring event from Outlook.
3. Connect into a user B with access to the event and edit all the events from the series.
4. Run the scheduled action to sync user A.
5. Many emails are going to be sent to the attendees from Outlook.

## Solution: 
With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook.

opw-4374503

Forward-Port-Of: odoo/odoo#252079
Forward-Port-Of: odoo/odoo#199663

Because a timeout in js only ensures to wait at least for that
amount of time while giving no upper bound to the actual awaited
time, it was possible for advanceTime(100) to actually wait for
more than 300ms when the runbot was slow enough. In that case,
since enough time has elapsed between the action and checking that
the toolbar hadn't opened yet, well it was actually already opened,
since we had waited too much, and the test failed non-deterministically.

This is actually a special case here. Usually we want to use `waitFor`
or `expectElementCount` with the toolbar since it's a popover and is
therefore affected by [1]. But we cannot use them to check if the
toolbar hasn't opened too early, lest we find ourselves with the same
problem than explained above. Using only advanceTime with a timeout of
100ms and a synchronous `expect` check ensures that, in the general
case when the runbot is fast, the test will fail in case of a regression,
since there would have been ample time to have multiple animation
frames during 100ms. The regression will only be hidden when the
runbot is very slow and no animation frame has happened during the
100ms timeout, which is an acceptable tradeoff.

The same issue appeared in another test so I fixed it as well.

Timeouts throughout this test file were excessive, with multiple uses
of `advanceTime(500)` while OPEN_TOOLBAR_DELAY is 300ms. This is because
the commit dates from before [1] and so it was hard to ensure that
enough time and animation frames had passed before we could check with
`expect`, which is synchronous. Now we are using `expectElementCount`,
which uses `waitFor` under the hood which has a proper mechanism to wait
for enough animation frames with an  additional internal delay. With
these, there is no more need for a manual timeout to exceed the value of
OPEN_TOOLBAR_DELAY. Note that this only applies to the cases where we
check that the toolbar should be displayed, since cases where it should
NOT be displayed before a certain timeout should NOT use those utils,
as explained above.

runbot-238562

[1]: https://github.com/odoo/odoo/commit/54da715df84789f9a1acc0cfc91be41dcdbab140

Co-authored-by: Sébastien Geelen <sge@odoo.com>

Forward-Port-Of: odoo/odoo#247551

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#106596

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#109262
Forward-Port-Of: odoo/enterprise#105040

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#106596

## Issue:
Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees.

## Steps to reproduce:
1. Connect to Outlook and Sync for user A.
2. Create a recurring event from Outlook.
3. Connect into a user B with access to the event and edit all the events from the series.
4. Run the scheduled action to sync user A.
5. Many emails are going to be sent to the attendees from Outlook.

## Solution: 
With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook.

opw-4374503

Forward-Port-Of: odoo/odoo#252079
Forward-Port-Of: odoo/odoo#199663

**Steps to reproduce:**
- Create a product tracked by lot, set it's price to 1000
- Create a quotation add a line with the created product and change the price to 1200
- Add another line with the same product and change it's price to 600
- Go to PoS and settle this quotation
- The lines' prices will be 1000 and 600 instead of 1200 and 600

**Why the fix:**
In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation.

This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set.

To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually.

opw-5223463

Forward-Port-Of: odoo/odoo#251883
Forward-Port-Of: odoo/odoo#238295

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#106596

Before this commit:
====================
In the Master Production Schedule (MPS) view, the `Order` and `Duration` buttons remain visible even when there are no MPS records. It leads to a confusing user experience, as actions are shown while no records are available to act upon.

Steps to Reproduce:
====================
1. Install `mrp` module.
2. Go to Settings → Enable `MPS` option.
3. Navigate to MPS → Delete all MPS records → the `Order` and `Duration` buttons are still visible.

Additionally, when MPS records span multiple pages and the user deletes all records from current page, the view is not refreshed to redirect the user to another page that still contains records.

Cause of the issue:
====================
- The visibility of the `Order` and `Duration` buttons was not tied to the presence of MPS records. The logic did not check whether any MPS records existed, so both remains visible even when no MPS records were present.

After this commit:
====================
This commit ensures that `Order` and `Duration` buttons are hidden when there are no MPS records. Additionally, the view is refreshed after deleting all records from a page, ensuring the user is redirected to a page with remaining
MPS records.

TaskID-5356994

**Steps to Reproduce:**
1. Open Payroll->Payslips->Pay Runs
2. Click on a Pay Run in Mobile View (Width < 600px).
3. Return to the previous view using the breadcrumb.
4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft')

**Bug Cause:**
The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback.

**Solution:**
Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout.

Task: 5971861

Forward-Port-Of: odoo/enterprise#108847

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/enterprise#106999

### Issue:
The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours.

### Steps to reproduce:
- Go to Planning app
- Create a shift for an employee from 3pm to 2am (over two days)
- The hours of the shift are displayed
- Modify the shift end to 3am
- The hours of the shift aren't displayed

### Cause:
Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c).

But as the pills are no longer truncated since 17.0, the computation of pill names is faulty.

### Solution:
We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it.

opw-5881532

Forward-Port-Of: odoo/enterprise#109548
Forward-Port-Of: odoo/enterprise#107233

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607

Forward-Port-Of: odoo/enterprise#109612
Forward-Port-Of: odoo/enterprise#107438

### Issue:
When deleting a payslip run, the documents from the payslips of the run are not deleted. This results in a traceboack when opening the document app.

### Steps to reproduce:
- Have a payslip run with payslips
- Go to a payslip, validate and generate the document
- Then cancel and reset to draft
- Reset the Payslip Run to draft
- Delete it
- Open the Documents app

### Cause:
The payslips are linked to the run with a `ondelete='cascade'` relation. 

https://github.com/odoo/enterprise/blob/03b2a7dae0e5c5ad3142ec2da8f3de5c9b1957f4/hr_payroll/models/hr_payslip.py#L110-L113

This means that deleting the run also deletes its payslips on a database level, bypassing the ORM. As the document is not directly linked by a relational field but instead by `res_model` and `res_id`, these fields are not updated and therefore are still pointing to a record that is no longer in DB.

### Solution:
Extend the `unlink()` method in `hr.payslip.run` and unlink the documents there.

opw-5501061

Forward-Port-Of: odoo/enterprise#109510
Forward-Port-Of: odoo/enterprise#105969

When a workspace(folder) linked to a folder setting is moved to the trash and
the ``Base: Auto-vacuum internal data`` cron runs, a traceback will generate.

Steps to reproduce the error:
- Install ``documents_account`` module
- Go to Documents > Configuration > Files Centralization > Enable Accounting > Select any workspace > Save >
- Click on Journals > Create a new > Select any Journal > Create a Workspace A > Save
- Go to Documents > Click on Workspace A > Actions > Move to trash
- Run the ``Base: Auto-vacuum internal data`` cron

Traceback:
```py
ForeignKeyViolation: update or delete on table "documents_document" violates foreign key constraint
"documents_account_folder_setting_folder_id_fkey" on table "documents_account_folder_setting"
```

solution:
override the ``_get_gc_clear_bin_domain`` method to exclude folders linked to folder settings,
preventing their deletion during the garbage collection.

sentry-7193540869

Forward-Port-Of: odoo/enterprise#109434
Forward-Port-Of: odoo/enterprise#104875

Description of the issue/feature this PR addresses:
This PR fixes an error occurring during the evaluation of the UBL/CII export condition when the country_code field on the invoice or its commercial partner is not set. In Odoo, unset fields may return False, which can lead to type comparison errors when performing membership checks against string values.

Current behavior before PR:
If invoice.country_code or invoice.commercial_partner_id.country_code is False, the condition that checks whether the country code is in ('FR', 'DE') may raise an error because a boolean value is being evaluated where a string is expected.

Desired behavior after PR is merged:
The condition safely handles cases where country_code is not set by normalizing the value before performing the membership check. This prevents type errors and ensures the logic behaves correctly even when the country code is missing.


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

### Issue:

When scanning products tracked by lot in the barcode app, if multiple move lines existed for the same product, all scanned quantities were incorrectly added to a single line. This left other lines unfulfilled and caused an unnecessary backorder.

#### To reproduce the issue:
1- Enable `Lots and Serial Numbers` in setting
2- Create a product and track it by lots
3- Create a PO, with 2 lines of each 1 quantity of our product
4- Go to barcode. From `receipt` operation find the PO picking
5- Scan the product and fulfill the line. You will have a line
   of 2/2 fulfilled. Validate.
6- As you see a backorder is created.
7- If you check the moves from PO, you can see there are 2
   lines with 2/1 and 0/1 qty_done which made the backorder

#### Cause:

This is caused because in addQuantity, the quantity increment is only applied to 1 line, ignoring the fact there might be multiple lines:
https://github.com/odoo/enterprise/blob/def740d23c006b97b60fd1a0cd5acadca8abfac6/stock_barcode/static/src/components/line.js#L118-L127

This will going to add all quantities to single line, making it ovefilled. Here the line will have the `qty_done` = 2 while its `quantity` is 1. The other line's qty_done remain 0, causing backorder.

### Fix:

We can first, make sure to fulfilling all lines, then if all are fullfilled and there are stil quantities to add, then it can be arbitrary added to one line.
We keep the current logic for negative quantitites, as the increment is only done by -1.

opw-5035778

…tion

Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move.

Steps to reproduce:
- Have the main company in USD and EUR as foreign currency
- Have a bank journal with currency EUR (Bank EUR)
- Create an xchange rate for today (1.1)
- Make a Payment (EUR), it should not have an associated move
- Put the payment in a batch
- Update the exchange rate for today (1.2)
- Create a Bank transaction in the journal Bank EUR matching the payment amount
- Open the bank reconciliation screen and reconcile the transaction with the batch

Expected result:
Everything is reconciled.

Actual result:
User gets an error message saying that the account move is not balanced.

Analysis:
The issue occurs because the reconciled payment amount is converted to the company currency using the date provided in the payment.  However the rate was changed in the meanwhile, so it does not match the amount that was used to create the exchange entry values.

opw-5164405