### Step to reproduce:
1. Create db in version 17.0 and create a many2one field
   with ``mail.partner.device``
2. neturalize the db. All records of res.users will be vanish due to  ``TRUNCATE mail_partner_device CASCADE;``

### Issue: 
during neutralize if there is any custom/studio field many2one with ``mail.partner.device`` even if the mail partner device
record won't used it in particular model still it will wipe out all the records of that model on neutrilizing
which can issue during testing on neutrlized db 

**To fix it :** 
 [here](https://github.com/odoo/odoo/pull/133560/files#diff-284b40b100919f9b1d4f7bee50740387fea5f11815210baa5f6de9cbf317ca6dR14) want to delete only partner device. So, adjusted query using ``DELETE FROM mail_partner_device`` instead of truncate.  

below traceback will generate due to this during upgrade.
```
Traceback (most recent call last):
  File "/home/odoo/bin/misc/update_module_list.py", line 25, in <module>
    env["ir.module.module"].update_list()
  File "<decorator-gen-87>", line 2, in update_list
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 71, in check_and_log
    log_data = (method.__name__, self.sudo().mapped('display_name'), user.login, user.id, origin)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1188, in __get__
    raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: res.users(1,), User: 1)
[ERROR]::Error during the upgrade:
```


opw-5443072
upg-3712726

Forward-Port-Of: odoo/odoo#242081
Forward-Port-Of: odoo/odoo#241535

**Steps to produce:**
- Install `Events and Sales` modules.
- Go to `sale > sale order > Open any SO > Add product > Event registration`.
- When the wizard opens, dismiss it by either clicking the X button in the
  top-right corner of the modal or by pressing the `Escape` key.

**Traceback:**
`TypeError: Cannot convert undefined or null to object.`

**Root cause:**
- In this [commit], the `{ dismiss: true }` option was added to the `dismiss` call.
- At [1], when `onClose` is triggered, we only check `!closeInfo || closeInfo.special`.
 Since `{ dismiss: true }` does not satisfy either condition, the code falls into the `else` branch,
 where `update` is called with an `undefined` value.

**Solution:**
- Now, we also check the condition `closeInfo.dismiss`.
- So, now that we have closed the selection of the event, our product is also removed from the SO line.

[commit]: https://github.com/odoo/odoo/commit/31c00161fd3a77c9fbd260754cb8c142fcb0d652
[1]https://github.com/odoo/odoo/blob/01a896557ec2bada04db60195926c6fa61375b10/addons/event_sale/static/src/js/sale_product_field.js#L40

**opw-5349732**


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

Forward-Port-Of: odoo/odoo#238061

An error occurs when a user tries to assign a Statement to multiple selected lines in the Bank Statement list view.

Steps to reproduce:
1) Install Accounting with demo data.
2) Open the Bank Reconciliation widget.
3) Switch to the List view.
4) Select multiple statement lines.
5) Click on the 'Statement' field to assign a statement to the selected
   lines.

Error:
`TypeError: Cannot read properties of undefined (reading 'root')`

Root Cause:
The `BankRecMany2OneMultiID` component attempts to access `active_ids`
through `this.env.model.root` (see [1]). During re-rendering, the value of
`this.env.model` becomes undefined, which leads to the error.

Fix:
Add a check for the existence of `this.env.model` in the getter to avoid
accessing `root` on an undefined model.

[1]- https://github.com/odoo/enterprise/blob/c194bee0e48db407288e3c402e71840af299568d/account_accountant/static/src/components/bank_reconciliation/list_view/list_view_many2one_multi_edit.js#L14

opw-5403564

Forward-Port-Of: odoo/enterprise#101792

[FIX] mail: avoid error on service worker push subscription change

Sometimes, the `pushsubscriptionchange` event is called without an
`oldSubscription` defined, which can lead to an error occurring inside
the  service worker.

Steps to reproduce:

1. Enable notification in Odoo.
2. Reset the permission in the Chrome interface
3. Re-enable the permission inside the discuss systray by clicking on
the Odoobot message.
=> The pushsubscriptionchange is called without an oldSubscription


[FIX] mail: ir_cron_web_push_notification are now more robust

With a user having 5 registered devices for push notifications
if a browser registers with an endpoint that has a wrong domain
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX
the cron job cannot resolve the invalid domain of the endpoint and ends
up disabling it.


[FIX] mail: push_to_end_point method to support .invalid TLD

if a browser registers with an endpoint that has a TLD `.invalid`
such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX

The TLD `.invalid`[1] is intended for use in online construction of
domain names that are sure to be invalid and which it is obvious at a
glance are invalid. The cron job cannot resolve the invalid domain of
the endpoint and ends up disabling it.

So we need to unregister a device with an endpoint with a `.invalid`
TLD.

[1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2


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

Forward-Port-Of: odoo/odoo#242013
Forward-Port-Of: odoo/odoo#240502

Steps to reproduce:

- Create service product with UoM 'pack of 20 hours' and prepaid policy
- Sell the product and confirm the Sales Order
- Create a helpdesk ticket/task linked to the Sales Order Line
- Log 22:00 on timesheets

Current behavior:
Sales Order Line shows '-2:01 remaining'

Expected behavior:
Should show '-02:00' to reflect two hours overconsumed without rounding.

Root cause:
Python's float type follows the IEEE 754 double-precision standard,
where only base-2 fractions can be stored precisely. Base-10 fractions
cannot be represented exactly, introducing tiny rounding errors.  
During chained operations such as multiple conversions or subtractions,
these small errors accumulate into larger discrepancies.  
The float_round() function uses a small constant epsilon to correct
rounding noise, but as arithmetic chains grow, errors exceed epsilon's
tolerance and it can no longer correct them.  
Since a single global epsilon cannot handle every case (small vs. large
values, chained vs. single operations, or regressions), rounding drift
is inevitable when rounding happens repeatedly.

Fix:
To prevent these rounding errors from compounding, the solution is to
stop intermediate rounding altogether. By using conversions with
round=False, all arithmetic is done in the base unit (hours) with full
float precision, and rounding is applied only once when displaying the
final value. This eliminates error accumulation and ensures consistent,
drift-free results.

task-5090240

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

Forward-Port-Of: odoo/odoo#241120
Forward-Port-Of: odoo/odoo#229282

The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and ugly.

The height of the indicators when outside influences the margin needed to align the bottom of the prev/next buttons. That caused the bottom of the next/prev buttons to not reach the bottom of the slide with "Numbers" or "Hidden" as indicators.

This commit adds the necessary css rules to correctly size and colors the number indicators (and the hidden one) when positioned outside.

Steps to reproduce
- Add a carousel
- Set "Indicators" to "Numbers"
- Set "Style" to "Indicators outside"
- Bug: The colors are all wrong, we cannot see the numbers
- Bug: The bottom of the previous/next buttons do not reach the bottom of the carousel
- Set "Indicators" to "Hidden"
- Bug: The bottom of the previous/next buttons is even further from the bottom of the carousel

task- 5358507

Forward-Port-Of: odoo/odoo#237397

The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow.

This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one.

This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line.

Benchmarks:

Importing a peppol document of 173 invoice lines.

| Num products | Num invoice lines | Before   | After   |
| ------------ | ----------------- | -------- | ------- |
| 864873       | 173               | 868.18 s | 19.43 s |
| 397005       | 173               | 468.91 s | 20.68 s |
| 8064         | 173               | 125.08 s | 20.1 s  |
| 564          | 173               | 119.9 s  | 20.21 s |

opw-5245007


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

Forward-Port-Of: odoo/odoo#240753
Forward-Port-Of: odoo/odoo#238853

## Versions
17.0+

## Issue
Customers located in French territories (e.g. La Réunion) can't use Stripe Connect.

## Steps to reproduce
*Ensure Stripe payment provider is installed*
- From the Settings' app, access your company's data:
  - Change your company's country for "Réunion".
- Go to Payment Providers and open Stripe:
  - Try to enable Stripe via Stripe Connect;
  - A message tells you your country is not supported by Stripe.

## Cause
Commit 94b37a3f51089621a2f12360c7a13f610b24ba3a introduced territories mapping by adding the method `_stripe_get_country()`, mapping the company country (`self.company_id.country_id.code`) to enable Stripe under the parent country as specified in their documentation (https://support.stripe.com/questions/stripe-availability-for-outlying-territories-of-supported-countries).
This fix was first applied in 16.0 and forwarded but didn't check that commit de782a680de8e5a2d7c89b982c485ca29da34b3a, from saas-16.2, added another condition on (`self.env.company.country_id.code`) on the Stripe Connect flow.

opw-5421185

Forward-Port-Of: odoo/odoo#242123
Forward-Port-Of: odoo/odoo#241269

Description of the issue/feature this PR addresses:
Based on this feedback : https://www.odoo.com/odoo/project.task/5436300 
. When I got two versions with different working schedules, normally, in Attendance, the gant view should show the unavaibilities by putting in gray days you're not working.
. As the feedback shows, if you have two differents working schedules on two differents versions and two differents occupations period (contract dates), it's working fine.
If, the two versions have the same occupation period (contract date), it's only considering the latest working schedule.
. If both versions are under the same contract, then it only shows the working schedule on the latest version. This is not what we expect 
Instead, it should show the correct working schedule for each period

Current behavior before PR:

Desired behavior after PR is merged:
. Modify _get_calendar_periods() method to return the correct working schedule for each period

task-5473047

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

In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order

### Steps to reproduce:

* Create a product with instantly generated variants
* Create a combo choice and add one of his variants
* Create a combo product and add the combo
* Open an store that sells this combo
* Select the combo and choose the product with variant and confirm the selection

Issue : On the left size in the order the variant name will not appear.

### Observation:

When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33

------------
When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered.
The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products.

opw-5037355

Forward-Port-Of: odoo/odoo#239314
Forward-Port-Of: odoo/odoo#227176

Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment.

Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices).

Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo.

Task-5187602
Community PR-[#232841](https://github.com/odoo/odoo/pull/232841)

Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081

Forward-Port-Of: odoo/enterprise#103350
Forward-Port-Of: odoo/enterprise#98029

**Issue**
A validation error is raised when creating a new spreadsheet template from a Quality Control Point.

**Steps to reproduce**
1. Open the Quality app.
2. Go to Quality Control > Control Points.
3. Click "New".
4. Set the type to "Spreadsheet".
5. Click on Spreadsheet Template > Search More.
6. Click "New".
-> A validation error is raised.

**Cause**
In `quality_view`:
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19
the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`:
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51

This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 
Since `name` is required:
https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12
validation fails.

**Solution**
Provide a default value for the `name` field, using the same default as in `documents_document.py`:
https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321

opw-5340710

Forward-Port-Of: odoo/enterprise#101671