**Steps to produce:**
- Install the `Sales` module.
- Create a Sales Order.
- Add a section and some products under it.
- In the section menu (three dots), click Set Optional.
- Again, open the section menu and click Unset Optional.

**Issue:**
- After unsetting the optional, the product amounts remain `0`.

**Root cause:**
- At[1], when setting options, both quantity and price are reset to `0`.
- When unsetting optional, only the quantity is restored, leaving the price at `0`.

**Solution:**
- When unsetting optional, explicitly trigger the onchange on the field `product_uom_qty` using `.update()`.

[1]https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L138-L140

Before:
<img width="1198" height="476" alt="image" src="https://github.com/user-attachments/assets/01dee1d6-2870-4222-8a6c-724fbfff8da1" />

After:
<img width="1214" height="453" alt="image" src="https://github.com/user-attachments/assets/63ed4eb4-27cf-4b15-a957-c28a46a3ca42" />

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

Forward-Port-Of: odoo/odoo#239805

### 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

Bug:

      - Create a new employee (also reproducible with existing employees)

      - Create a Paid Time Off allocation that becomes available in the future

      - Create a Time Off request for this employee at a future date

      - When selecting the Time Off type, it shows “0 remaining out of 0 days” even though leave has been allocated

Reason:
In `_compute_display_name`, the record is accessed using `self.sudo().` Switching to superuser triggers `_compute_leaves`, but the context is lost and therefore the `target_date` is lost as well.
In `get_allocation_data`, because target_date is False, it is replaced with today’s date. This causes `max_leaves` and `virtual_remaining_leaves` to be computed as of today instead of the intended future date.

Fix:
Remove the `sudo() `and use the current user context instead.

-------------------------------------------------------------------------------
Test fix: `test_allocation_dropdown_after_period`

Bug:
After removing `sudo() `from `_compute_display_name`, the test fails and shows “0 remaining out of 0” instead of “9 remaining out of 9”.

Reason:
The test user (Admin) did not have the employee’s company in their allowed companies.
The `name_search` method triggers `_compute_display_name`, which triggers the computation of virtual_remaining_leaves.

Before the fix, `_compute_display_name` used `sudo()`, which propagated superuser privileges down to `_compute_leaves` and `get_allocation_data`. This masked the fact that the test user did not have access to the employee’s company (multi-company rule).

After removing `sudo(),` the user no longer had access to the allocation when running `name_search`, causing the test to fail.

Fix:
Add the employee’s company to the user’s company_ids. This allows allocations and `name_search` to work correctly without using `sudo().`

-----------------------------------------------------------------------
Known limitation:
When booking time off from the employee calendar view, the default value of `holiday_status_id` in the Time Off request widget still calculates remaining days based on today’s date instead of date_from.

To avoid confusion, the display name does not include “(x days remaining out of y days)” in this context.
However, when opening the selection dropdown, the display name is correct and uses the proper date-based calculation.

Steps To Reproduce
------------------

1- Go to Accounting > Vendors > Bills.
2- Upload a UBL XML file containing both RegistrationName and Contact/Name (you can use one of the two attached in the ticked).
3- Check the Vendor field.

Issue
-----

The vendor name is set to the contact person name instead of the company's legal name.

Cause
-----

In `_import_retrieve_partner_vals`, the XPath prioritizes `cac:Contact//cbc:Name` (contact person) over `cbc:RegistrationName` (company legal name).

Fix
---

Swap the priority to check `RegistrationName` first, falling back to `Contact/Name` only when no registration name exists.

Legal/Standards Proof (OASIS UBL 2.1 Specification) according to sources:

https://www.datypic.com/sc/ubl21/e-cac_PartyLegalEntity.html
- cbc:RegistrationName: "The name of the party as registered with the relevant legal authority."

http://www.datypic.com/sc/ubl21/e-cac_Contact.html
- cac:Contact/cbc:Name: "The name of this contact. It is recommended that this be used for a functional name and not a personal name."

The RegistrationName is the official legal company name, while Contact/Name is just a contact point at the company.

Test
------
For the test I updated a test file so that `test_import_partner_fields` fails without these changes.


opw-5392139

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

Forward-Port-Of: odoo/odoo#242046

[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#242428
Forward-Port-Of: odoo/odoo#240502

When using a promotion program applied only on specific products with
tax included prices, the discount value was incorrect.

Steps to reproduce:
-------------------
* Create a product with a price of 100$ and tax of 10% included
* Create a promotion program with:
  - Apply on: Specific Products (the product created above)
  - Discount Type: $ Fixed Discount
  - Discount Value: 10$
* Open PoS and add the product to the order
* Apply the promotion code
> Observation: The value of the discount is 9.09$ instead of 10$

The same steps also applies to the discount reward applied on the whole
order.

Why the fix:
------------
When computing the discountable amount for the promotion it would take
the amount excluding tax instead of the base price. The base price
should be the unit price of the product multiplied by the quantity. As
it was before here :
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474
https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112
To do so we modified the accounting helpers to provide this value
instead of computing it manually.

opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task)
opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#240289

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

This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets.

**Accordion issues**
How to reproduce: drop two nested `s_accordion` snippets. Then:
1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change,
2. Change the outer "Round Corners" -> both accordion change,
3. Change the outer "Icon Position" ->  both accordion change,
4. Change the outer "Icons" style -> both accordion change.

**Blockquote issues**
How to reproduce: drop two nested `s_blockquote` snippets. Then:
1. Change the outer "Decoration" -> both blockquotes change,
2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too,
3. Change the outer "Author Alignment" -> only the inner blockquote changes.

**Cause**
The above issues occur because certain `applyTo` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited.

**Fix**
The relevant `applyTo` and CSS rules now use more specific selectors.

**Note**
See also https://github.com/odoo/odoo/pull/237733

task-5362171

Forward-Port-Of: odoo/odoo#242077