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

Forward-Port-Of: odoo/odoo#241973

When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised.

Steps to reproduce the error:
- Install ``account`` and ``web_studio``
- Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo
- Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report
- Login as Mitchell Admin, remove administrator right of Marc Demo
- In Mark Demo, Open the duplicated report

Traceback:
```py
UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``.
For users without the required permissions, this ``search()`` raises an AccessError.

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400
Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound.
However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``.

sentry-7149350379

Forward-Port-Of: odoo/enterprise#103017

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#103338
Forward-Port-Of: odoo/enterprise#101792

Steps to reproduce:
----------------------------
1. Install Field Service module
2. Open any task from Field service module
3. In the Planned date field set a wide range spanning years, for example: Dec 16, 2024, 1:30 PM → Oct 13, 2026, 6:00 PM.
4. Go back to kanban view
5. Adjust display to around 360 px

Observation:
----------------------------
The planned date daterange widget overflows and extends outside the kanban card, breaking the card layout and visual containment.

Issue:
----------------------------
The daterange widget's parent container did not enforce a width, so the widget could grow beyond the kanban card boundary when a long date range was used.

Solution:
----------------------------
Add the w-100 class to the daterange container div to enforce full-width layout within the kanban card.


Before:
<img width="584" height="529" alt="before_css" src="https://github.com/user-attachments/assets/e89302b0-975c-47eb-91ec-89dbfe813493" />

After:
<img width="561" height="528" alt="after_css" src="https://github.com/user-attachments/assets/48b60a78-18da-4504-98ef-a9c4013b107b" />


opw-5219941

Forward-Port-Of: odoo/enterprise#102093

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

When the ``Default 48 hours/week`` working schedule is deleted and
the ``Payroll: Update data`` cron runs, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_mx_hr_payroll`` module with demo data
- Switch to ``INNOVACION VALOR Y DESARROLLO SA SA`` company
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Default 48 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron

Traceback:
```py
ValueError: External ID not found in the system: l10n_mx_hr_payroll.resource_calendar_def_48h

ParseError: while parsing /home/odoo/src/enterprise/l10n_mx_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="l10n_mx_employee" model="hr.payroll.structure.type">
        <field name="name">Mexico: Employee</field>
        <field name="default_resource_calendar_id" ref="l10n_mx_hr_payroll.resource_calendar_def_48h"/>
        <field name="country_id" ref="base.mx"/>
    </record>
```

The ``Payroll: Update data`` cron updates payroll data that references the ``Default 48 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists, leading to the above traceback.

sentry-7166574553

Forward-Port-Of: odoo/enterprise#103323

Problem:
When sending an email marketing, some images are not visible in the received email.

Cause:
After 354b8f60dbabcfac690d90bf657592e1347e4f86, we clone the `editable`, append it to `processingContainer`, and call `toInline` on it.
During `toInline`, images with the `.card-img-top` class are queried and their size is fixed using `getComputedStyle`.

Because the editable is freshly cloned, images may not be loaded yet. Calling `getComputedStyle` on an unloaded image returns a height of `0`, which results in images being rendered as invisible.

Solution:
After cloning the editable, wait for all images inside it to finish loading before running `toInline`. This ensures `getComputedStyle` returns the correct dimensions.

Steps to reproduce:
- Open Email Marketing.
- Add a Columns snippet with images.
- Send the email.
- Observe that the received email is missing some images.

opw-5215534

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

Forward-Port-Of: odoo/odoo#240530

*mrp_account, sale_mrp{,_margin}, point_of_sale

## Issue 1: Kit sale price
 
### Steps to reproduce:

- Install sale_margin, sale_management, mrp
- Create a kit product with an avco product category:
    - 1 x COMP1, cost 10
    - 1 x COMP2, cost 20
- On the kit product update the cost accroding to the bom
- Create an SO for 1 unit of your kit
- Validate the associated receipt
#### > The cost (purchase_price) of the sol of the kit has been reset from 30 to 0.

### Cause of the issue:

Validating the receipt will trigger the dependence of the `purchase_price` compute method since the moves are now done: https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_margin/models/sale_order_line.py#L15-L18 However, the `_get_price_unit` will `return 0` since `sol` is linked to both component moves:
https://github.com/odoo/odoo/blob/18dc738c710f87d1f937b0d1fbb619c75f5ad952/addons/sale_stock_margin/models/sale_order_line.py#L10-L20

### Issue 2: POS with multiple products
Currently, when a pos order contains more than 1 product, inventory valuation lines are not generated when invoicing the order.

Steps to reproduce:
-------------------
* Using anglo-saxon accounting
* In the settings search for inventory valuation
  * Set inventory valuation to Perpetual
  * Choose standard cost method
  * Set up valuation account and journal
* Create two different products
  * Type -> Goods
  * Track inventory by quantity
  * Set a purchase cost
  * Put some quantity on hand
  * Add category
* In the settings of the category
  * Set up Stock account
  * Set up costing methog, standard
  * Set inventory valuation to perpetual
* Open pos session
* Make 3 orders, invoice them
  * Order 1, only product 1
  * Order 2, only product 2
  * Order 3, both products
> Observation: The invoces for orders 1 & 2 have entries regarding
inventory valuation while the invoice for order 3 does not have any.

### Cause of the issue:

Stock valuation entries are not created for order 3 because the price unit computed is 0.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/account_move.py#L122-L126

The reason why the price unit is 0 is because in `_get_pos_anglo_saxon_price_unit` we have multiple records in `moves` related to multiple products.
https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/point_of_sale/models/pos_order.py#L276-L281

`_get_price_unit` was not designed to treat moves with different products https://github.com/odoo/odoo/blob/008e69e8215fecc1f3fe45a36189592577cdc593/addons/stock_account/models/stock_move.py#L225-L228

This leads to think we should filter moves in `_get_pos_anglo_saxon_price_unit` regarding the product.

The end result is now the same as when we make a SO with the two products in the Sales app and invoice it. This results in 2 valorisation lines (1 per product) but this does not change the valorisation when the pos order is not invoice and we close the session (still 1 valorisation line).

### Fix:

The filter on the product_id in the `_get_pos_anglo_saxon_price_unit` has been removed in https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229
Prior to that change the price unit were computed on moves sharing a common product:
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/point_of_sale/models/pos_order.py#L271-L275
https://github.com/odoo/odoo/blob/9cb6476e0f8d319dce4baf65904b8bd5d535c83c/addons/stock_account/models/stock_move.py#L28-L29
We reintroduce this filter as it should not have been removed.


#### Issue 1: opw-5420977
#### Issue 2: opw-5328152

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

Forward-Port-Of: odoo/odoo#242052

## 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#103354
Forward-Port-Of: odoo/enterprise#101174

## 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#242319
Forward-Port-Of: odoo/odoo#241269

## 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#103354
Forward-Port-Of: odoo/enterprise#101174

When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised.

Steps to reproduce the error:
- Install ``account`` and ``web_studio``
- Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo
- Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report
- Login as Mitchell Admin, remove administrator right of Marc Demo
- In Mark Demo, Open the duplicated report

Traceback:
```py
UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``.
For users without the required permissions, this ``search()`` raises an AccessError.

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400
Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound.
However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``.

sentry-7149350379

Forward-Port-Of: odoo/enterprise#103017

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

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

Forward-Port-Of: odoo/odoo#241973

## 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#103354
Forward-Port-Of: odoo/enterprise#101174

When a user sets an invalid video link for a slide, a traceback occurs.

Steps to reproduce the error:
- Install ``website_slides`` module with demo data
- Go to Website > Courses > Open Taking care of Trees course
- Add Content > Video > Add valid video link (ex. https://www.youtube.com/shorts/SXHMnicI6Pg) > Save and Publish > Delete
- Repeat above step
- Add content > Video > Add any text in video link > Save and Publish

Traceback:
```py
AssertionError: Could not find all values of slide.slide(12,) to flush them
```

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/website_slides/controllers/main.py#L1363-L1372
New record is created using ``new()`` to fetch external metadata for the slide.
This record only exists in memory and is not stored in the database.
When the video link is invalid, ``video_source_type`` is False, and the code attempts to ``unlink()`` the slide.
Unlinking the record triggers field recomputations,
and it will lead to the above error when flushing the new record.

ref: https://github.com/odoo/odoo/commit/71233fa2cb8984b65f8e7ac55405fdbc054756a0

sentry-6964031088

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

Forward-Port-Of: odoo/odoo#235099

When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised.

Steps to reproduce the error:
- Install ``account`` and ``web_studio``
- Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo
- Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report
- Login as Mitchell Admin, remove administrator right of Marc Demo
- In Mark Demo, Open the duplicated report

Traceback:
```py
UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``.
For users without the required permissions, this ``search()`` raises an AccessError.

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400
Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound.
However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``.

sentry-7149350379

Forward-Port-Of: odoo/enterprise#103017

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised.

Steps to reproduce the error:
- Install ``account`` and ``web_studio``
- Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo
- Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report
- Login as Mitchell Admin, remove administrator right of Marc Demo
- In Mark Demo, Open the duplicated report

Traceback:
```py
UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``.
For users without the required permissions, this ``search()`` raises an AccessError.

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400
Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound.
However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``.

sentry-7149350379

Forward-Port-Of: odoo/enterprise#103017

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/ac2fa3e6d4 [REL] 19.2.0-alpha.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/811ec6d6d2 [FIX] session: always return a Promise [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/900df13338 [FIX] session: recover from errors when sending messages [Task: 5469116](https://www.odoo.com/odoo/2328/tasks/5469116)
https://github.com/odoo/o-spreadsheet/commit/f832009ebf [REF] side_panel: rename CSS classes for clarity [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/ada17cb231 [REF] side_panel: split CF into main and editor panels, use store [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/c3ee9f24ab [REF] side_panel: separate data validation list and editor logic [Task: 4982596](https://www.odoo.com/odoo/2328/tasks/4982596)
https://github.com/odoo/o-spreadsheet/commit/f255b8720d [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580)
https://github.com/odoo/o-spreadsheet/commit/f19bf803a4 [IMP] cf: add top10 conditional formatting operator [Task: 5367065](https://www.odoo.com/odoo/2328/tasks/5367065)
https://github.com/odoo/o-spreadsheet/commit/559cdd8ff1 [FIX] dashboard: properly handle grid resize in dashboard mode [Task: 5223156](https://www.odoo.com/odoo/2328/tasks/5223156)

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>

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

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

Forward-Port-Of: odoo/odoo#241153
Forward-Port-Of: odoo/odoo#217125

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.

Forward-Port-Of: odoo/odoo#241448

[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

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

Forward-Port-Of: odoo/odoo#241973

## 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#103354
Forward-Port-Of: odoo/enterprise#101174

When a user sets an invalid video link for a slide, a traceback occurs.

Steps to reproduce the error:
- Install ``website_slides`` module with demo data
- Go to Website > Courses > Open Taking care of Trees course
- Add Content > Video > Add valid video link (ex. https://www.youtube.com/shorts/SXHMnicI6Pg) > Save and Publish > Delete
- Repeat above step
- Add content > Video > Add any text in video link > Save and Publish

Traceback:
```py
AssertionError: Could not find all values of slide.slide(12,) to flush them
```

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/website_slides/controllers/main.py#L1363-L1372
New record is created using ``new()`` to fetch external metadata for the slide.
This record only exists in memory and is not stored in the database.
When the video link is invalid, ``video_source_type`` is False, and the code attempts to ``unlink()`` the slide.
Unlinking the record triggers field recomputations,
and it will lead to the above error when flushing the new record.

ref: https://github.com/odoo/odoo/commit/71233fa2cb8984b65f8e7ac55405fdbc054756a0

sentry-6964031088

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

Forward-Port-Of: odoo/odoo#235099

When a user opens a duplicated report in Studio after their administrator rights are removed, a traceback is raised.

Steps to reproduce the error:
- Install ``account`` and ``web_studio``
- Login as Mitchell Admin > grant Administrator and Invoicing Administrator rights to Mark Demo
- Login as Mark Demo in incognito tab > Open invoices > Open studio > Reports > duplicate any report
- Login as Mitchell Admin, remove administrator right of Marc Demo
- In Mark Demo, Open the duplicated report

Traceback:
```py
UnboundLocalError: cannot access local variable 'studio_view' where it is not associated with a value
```

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L379 The bug occurs because ``_get_and_write_studio_view()`` method performs a search on ``ir.ui.view`` before returning ``studio_view``.
For users without the required permissions, this ``search()`` raises an AccessError.

https://github.com/odoo/enterprise/blob/58dc97cb5a7185dc2acd801bb3af0e6c35add0b6/web_studio/controllers/report.py#L393-L400
Since this exception is raised before the assignment completes, the local variable ``studio_view`` is never bound.
However, the finally block of ``deactivate_studio_view`` is always executed and attempts to access ``studio_view.active``, resulting in an ``UnboundLocalError``.

sentry-7149350379

Forward-Port-Of: odoo/enterprise#103017

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

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#103338
Forward-Port-Of: odoo/enterprise#101792

[FIX] website_sale, adding website_id in portal controller

Version: 17.0+e

Steps to reproduce
------------------
The database has two different websites.

A payment provider is enabled for just one of them (website1).

When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1.

The problem also occurs when previewing the customer’s portal view.

Why it's happening
------------------
When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions.

As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible.

The Fix
-------
We now add the current website's id to the method if none has been added before.


opw-5172444, “Payment provider visible on sales order portal"


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

Forward-Port-Of: odoo/odoo#235954

Before this commit:
-------------------------
The sequence used in the template key was computed based only on the last active template.
If the next sequence number corresponded to an inactive template, the system could end up generating duplicate template keys — one for the inactive template and one for the newly created active template.

After this commit:
-----------------------
The sequence for the template key is now computed based on the last template, regardless of whether it is active or inactive.
This ensures that template keys remain unique across all report templates.

Why this commit:
-----------------------
if a template is inactive, the report engine should raise an error. However, because duplicate template keys were being generated, the inactive template could silently fall back to the active template with the same key, preventing the expected exception and bringing customization of one report to another. Additionally, if the inactive template is later corrected and reactivated, both reports would still reference the same template (the one with the smaller ID) because they shared identical template keys.
This fix prevents such conflicts by ensuring unique template key generation.

Forward-Port-Of: odoo/enterprise#101894

…me tokens greedily.

Fixes issue #241004 and is a cleaned up version of a previous PR https://github.com/odoo/odoo/pull/241033

This is a hard to reproduce bug because it depends in what order the FORMULA_ALLOWED_TOKENS set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this:

There might be taxes that do a different calculation depending on the base. So for example, we might need to do a formula like this:

(base >= 100) and (base * 0.05) or (base * 0.07)

<img width="1302" height="651" alt="Captura de pantalla 2025-12-26 a la(s) 11 17 02" src="https://github.com/user-attachments/assets/7ce16272-56a4-452b-8eba-e797442f68c2" />

This formula multiplies the base by a certain value depending on whether the base is greater or equal than 100.

This formula will work sometimes, but sometimes, it will fail with this error.

<img width="1302" height="615" alt="Captura de pantalla 2025-12-26 a la(s) 11 18 48" src="https://github.com/user-attachments/assets/5527ff5d-6747-4221-b54f-085e0603aa5a" />

The position of the error is the '=', because the '=' is not a valid token in this list:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L10.

The formula is not using just the '=' token in this formula. The formula is using the '>=' token and '>=' is an allowed token. So why this error  appears sometimes?

So here is the important thing and why this bug appears only sometimes: FORMULA_ALLOWED_TOKENS is not a tuple. It is a set. And sets iterate randomly (it is an unordered list). So the loop in this line:

https://github.com/odoo/odoo/blob/18.0/addons/account_tax_python/models/account_tax.py#L127

sometimes sees the token '>=' first, and sometimes sees the token '>' first in its cycle.

When the '>=' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>=' first so it advances 2 positions. In this scenario, the validation does not fail.

But when the '>' is first in the set of allowed tokens, the loop goes through the formula, trying to match substrings to each token in the set. It matches the '>' first so it advances 1 position. It has consumed only the '>' of '>='. Now, it will try to match the lone '=' to any of it tokens in the set of allowed tokens, but this '=' will not match any of the allowed tokens, so it will fail.

You can reproduce this bug using the above formula, and restarting Odoo if the error does not appear. Eventually, after restarting, the FORMULA_ALLOWED_TOKENS will have the '>' first and trigger the error.

The important part to understand here is that FORMULA_ALLOWED_TOKENS is unordered, so, the order of the loop is not guaranteed and sometimes this error is triggered and sometimes it is not, depending on the order the loop is done.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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