Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0.

**Steps to replicate:**
* Install `accountant` and `hr_expense` with demo.
* Enable analytic accounting from settings.
* Expense > Approve and Post submitted expense
* Analytic Accounts > Nebula > Vendor Bills

**Observed Behaviour:**
* Even though the smart button shows a count of 1 there are no records displayed in the list view.

**Root cause:**
* After PR [1], vendor bills were changed to receipts. Since [2] counts receipts too, the button shows a different count than the list view, as [3] does not include receipts.

**Solution:**
* Show purchase receipts along with the vendor bills which correctly matches with the vendor bill count.

[1]:
https://github.com/odoo/odoo/pull/217758
[2]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L36 
[3]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L68

opw-5359320

Forward-Port-Of: odoo/odoo#238282

**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:

- 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

Commit [1] introduced new groups for VoIP: admin and officer. Before that, the related rights came with the base admin group of Odoo. With that in mind, it made the new groups implied by the base admin group, but put them in a noupdate area of the security XML file, meaning only new databases would get the new groups assigned to the admin group.

There were two possibles solutions:
- An upgrade script to add the new groups to admin users (and/or the fact it is implied by the admin group).
- Move the group definitions to a non-noupdate area, which re-forces the fact the VoIP groups are implied by the admin group at each upgrade, to any Odoo version.

There is no guideline about this in Odoo and it is left to a per-app per-group choice. After consultation, the second solution was chosen: we prefer to enforce the fact that each new VoIP codebase, each version, relies on the fact admins are supposed to have those VoIP rights; forcing any customization of that fact to re-check it is working at each Odoo upgrade (and/or make a proper customization with custom apps instead of user manipulation).

[1]: https://github.com/odoo/enterprise/commit/88b8de95e1a28a8037a386fc8fb6a044a98217e7

task-5440305

Forward-Port-Of: odoo/enterprise#103348

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

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

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

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

[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

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

**Steps to produce:**
- Install `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Forward-Port-Of: odoo/enterprise#103223
Forward-Port-Of: odoo/enterprise#100587

### 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 `sale_subscription,website_sale` module.
- `Subscription > Configuration > Recurring Plans`.
- `Archive` the `Monthly` plan.
- Go to website > Shop > Open product `Car Leasing (SUB)`.

**Issue:**
- Even after archiving the Monthly recurring plan, its pricing still appears on the website product page.

**Root cause:**
- At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans.
- As a result, inactive plans are still considered during pricing selection.

**Solution:**
- In this fix, we ensure that recurring plan pricing is included only if the related plan is active.
- Archived plans are now ignored, preventing them from appearing on the website.

[1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79

before
<img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" />

after
<img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" />

**opw-5266333**

Forward-Port-Of: odoo/enterprise#103223
Forward-Port-Of: odoo/enterprise#100587

## Current behaviour:
When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order.

## Expected behaviour:
If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order.

## Steps to reproduce:
1. Validate a delivery order integrated with Starshipit.
2. Trigger a label generation failure (e.g., bad address).
3. Observe that the created Starshipit order is deleted.

## Cause of the issue:
The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order.

## Fix:
Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual.

## Additional note:
The _() wrapper in the error line was removed because
the Starshipit service has no env or language context.
Since translations cannot be resolved there, Odoo raised a warning.
Removing _() avoids this warning and keeps the error clean.

opw-5306979

Forward-Port-Of: odoo/enterprise#101174

[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

Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0.

**Steps to replicate:**
* Install `accountant` and `hr_expense` with demo.
* Enable analytic accounting from settings.
* Expense > Approve and Post submitted expense
* Analytic Accounts > Nebula > Vendor Bills

**Observed Behaviour:**
* Even though the smart button shows a count of 1 there are no records displayed in the list view.

**Root cause:**
* After PR [1], vendor bills were changed to receipts. Since [2] counts receipts too, the button shows a different count than the list view, as [3] does not include receipts.

**Solution:**
* Show purchase receipts along with the vendor bills which correctly matches with the vendor bill count.

[1]:
https://github.com/odoo/odoo/pull/217758
[2]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L36 
[3]:
https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L68

opw-5359320

Forward-Port-Of: odoo/odoo#238282

**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.push.device``
2. neturalize the db. All records of res.users will be vanish due to  ``TRUNCATE mail_push_device CASCADE;``

### Issue: 
during neutralize if there is any custom/studio field many2one with ``mail.push.device`` even if the mail push 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_push_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

When users would follow the following step as they are makeing a private task,  they would be hit by an incorrect access error.

### Steps to reproduce:
1.Open the form view to create a new task.
2.Clear the Project field. When empty, it should display the Private placeholder. 3.Ensure no user is assigned to the task.
4.Create the private task.
5.An access rights error occurs, stating that the user does not have permission to create the record.

#### ⚠️ Note:
This access rights error only occurs when the task is created directly as private. If a task is created normally and then its project_id and user_ids are removed afterward, no access rights error occurs.

### Root cause:
When a task is created without a project_id and without assigned users, Odoo checks access rights on creation. Since no project members or assigned users exist, no user has access to the record, including the creator. This results in an access rights error during creation.

This issue does not occur when modifying an existing task because, after creation, the creator is automatically added as a follower. As a follower, the creator retains access to the task even if it has no project and no assigned users.

### Fix (implemented):
Tasks that have no assigned users and are not linked to any project (private tasks) did not make sense, as they were effectively assigned to nothing.
To address this, we now require at least one user to be assigned to a task when it is not attached to a project.  This change was made inside of the "project_task_view.xml" file in the "view_task_form_2" record

Task:  [5403926](https://www.odoo.com/odoo/project/4105/tasks/5403926)
Version: 19.2a1+e
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#101866
Forward-Port-Of: odoo/enterprise#99373

Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed.

Problem 1: If ZATCA does not properly receive the invoice generated
from a POS order (wrong onboarding, wrong details on company, etc.)
the invoice printed from POS will not contain the QR code, even after
successfully resubmitting the invoice to ZATCA, load the order and 
reprint the invoice to see this

Testing the fix: Change the VAT number on the company to be faulty, 
create a POS order, Fix the VAT number and resubmit the invoice, load
the POS order and reprint invoice, it will now show the QR code.

Problem 2: When disabling the E-invoicing for a phase 2 journal,
the POS receipt will still try to print the phase 2 QR code but the system
will flag it as 'not legal' leaving the POS receipt empty, when it should
instead print the phase 1 QR code

Testing the fix: On the journal, disable the E-invoicing, and create a POS
order, it will now show the phase 1 QR code on the receipt

task-5032474

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

**AllowanceDate**:
l10n_tw_edi_ecpay has an issue on Credit Notes (Allowances).
When we `_l10n_tw_edi_generate_issue_allowance_json()`, we send the
`l10n_tw_edi_invoice_create_date` which is was set to the associated
invoices creation date, and not the Allowance's creation date.

This creates a potential issue where allowances issued more than 6 days
after the original invoice would bounce back from ECpay with errors.
To be consistent with invoices send to ECPay, we do not send the
`AllowanceDate` parameter at all

Manual Testing/Verification:
1. Create an invoice that has a `l10n_tw_edi_invoice_create_date`,
visible in the Invoice's ECPay tab more than 6 days ago. (Requires
sending to ECPay via the custom wizard via the "Send" button)
2. Create a credit note from the invoice and send to ECPay.
3a. Before this, see that an error would appear.
3b. Now, there would be no error

*InvoiceRemark*:
When Customer Reference `ref` is not set, the code sets the parameter
value as `False`, displaying it's string on the e-invoice and official
printout. We only set the parameter if there exists the `ref` now,
eliminating the issue.

Tests:
1. (both cases) undo the `account_move.py` changes and run the tests.

task-[5455847](https://www.odoo.com/odoo/project/967/tasks/5455847)

---

# New test failed output
<img width="1458" height="353" alt="image" src="https://github.com/user-attachments/assets/77df8e51-5005-4d99-985c-71757c0f62a6" />

```bash
07:47:53,055 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_01_can_generate_file
Traceback (most recent call last):
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 61, in test_01_can_generate_file
    self.assertIsInstance(json_data["InvoiceRemark"], str)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False is not an instance of <class 'str'>
 
07:48:02,516 ERROR l10n_tw_edi_ecpay-demo-vy2vd3s0 odoo.addons.l10n_tw_edi_ecpay.tests.test_edi: FAIL: L10nTWITestEdi.test_13_b2b_refund_upload_deadline_restriction
Traceback (most recent call last):
  File "/home/odoo/odev/virtualenvs/18.0/lib/python3.13/site-packages/freezegun/api.py", line 885, in wrapper
    result = func(*args, **kwargs)
  File "/home/odoo/odev/worktrees/18.0-l10n_tw_edi_ecpay-fix-allowance-date-erle/odoo/addons/l10n_tw_edi_ecpay/tests/test_edi.py", line 430, in test_13_b2b_refund_upload_deadline_restriction
    self.assertNotIn("AllowanceDate", json_data,
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "B2B Allowances should not include AllowanceDate to avoid >6 day limit errors."
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
AssertionError: 'AllowanceDate' unexpectedly found in {'MerchantID': '1234', 'Details': [{'OriginalInvoiceNumber': 'AB11100099', 'OriginalInvoiceDate': '2025-01-06', 'OriginalSequenceNumber': 0, 'ItemName': 
                                                                                                                                                                                                              'product_a', 'ItemCount': 1.0, 'ItemPrice': 1000.0, 'ItemAmount': 1000.0}], 'TotalAmount': 1000.0, 'TaxAmount': 50.0, 'CustomerEmail': 'partner_b@tsointsoin', 'AllowanceDate': '2025-01-06 15:00:00'} : B2B 
                                                                                                                                                                                                            Allowances should not include AllowanceDate to avoid >6 day limit errors.
```

---

Things to think about:
- FWP
- [ ] 19.0
- [ ] master

## Description of the issue/feature this PR addresses:
`compute_is_storable` is called when the `type` value is modified but the `write` function is never called when the value is set using the `is_storable` attribute. Updating `is_storable` using a `write` ensure that an exception is raised when move line exists.

But this fix addresses the symptom, not the underlying issue. So why ? Is it related to the cache or unit test environment ? 

## Current behavior before PR:
In a Unit test, If you convert a consumable and storable product to a service, no exception is raised, even with existing stock moves.
Unlike the previous version of Odoo (<15.0), where an exception was raised when the product type was changed and stock movements existed, detection now occurs if the ‘is_storable’ status is changed. However, this detection is not triggered if the value of ‘is_storable’ is defined by its attribute.

## Desired behavior after PR is merged:
An exception must be raised (like Odoo 14.0)



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

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code:
https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

__
opw-5136861


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