Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Forward-Port-Of: odoo/enterprise#117564

Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting.

* Introduce dedicated work entry types for:

  * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81)
  * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1)
* Add salary rules and categories for voluntary overtime remuneration.
* Enforce yearly thresholds through payroll parameters:

  * 240h for voluntary overtime exempt from ONSS
  * 120h for voluntary overtime subject to ONSS
* Exclude voluntary overtime from employment bonus calculations and paid amount computation where required.
* Include voluntary overtime remuneration in payroll calculations and DMFA declarations.
* Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields.
* Fix DMFA service hour computation and add payroll/DMFA test coverage.

TaskID: 6275791

Forward-Port-Of: odoo/enterprise#119355

## Description of the issue/feature this PR addresses

The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section.  

This affects not only external modules but also internal ones that add menu items under *Contacts*.

## Current behavior before PR

When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy.

<img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" />

## Desired behavior after PR is merged

The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules.

<img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" />



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

Forward-Port-Of: odoo/odoo#234909

### Description of the issue/feature this PR addresses:

getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days.

So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1.

The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week.

### Current behavior before PR:

At the end of 2026, this will cause problems because the week number will run as:

* 2026, week 52 (all days in 2026, OK)
* 2027, week 53 (most days in 2026, last day in 2027, Not OK)
* 2027, week 1 (all days in 2027, OK)

### Desired behavior after PR is merged:

This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as:

* 2026, week 52 (no changes)
* 2026, week 53 (year is not incremented if week number is not reset)
* 2027, week 1 (no changes, but year is incremented when week number is reset)

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

Forward-Port-Of: odoo/odoo#267871
Forward-Port-Of: odoo/odoo#267656

[FIX] voip: make sure any create/write on voip.call syncs user presence
    
    Commit [1] introduced a "in-call" presence icon. Before this commit,
    code updating call records had to call a specific function if user
    presence potentially had to be changed after the record update. While
    not hacking create/write to do that might be prettier, it is also
    subject to mistakes and one was already made: demo data call record
    creation did not update user presence properly. Commit [2] indeed
    introduced calling/ongoing call demo data and the user presence was not
    correct just after database initialization.
    
    This commit fixes that by now potentially syncing in writes and always
    syncing on create.

[FIX] voip: unstuck user call presence sooner in case of stuck calls
    
    At the moment, the Odoo phone has a freshness system for call records
    that appear still calling/ongoing for a strange duration. Indeed, there
    are still cases where a call ended and we could not detect it. For
    example, the user simply closing the tab where a call is ongoing (we try
    to warn the user before he leaves but if agrees to leave anyway, the
    call is just stopped when connexions are lost but the call record stays
    marked as "ongoing"). In those cases, we have 2 things:
    
    - A once-a-month cron checks all cases that are calling for more than
      5 minutes or ongoing for more than 4 hours. It moves them to "ended
      unexpectedly".
    
    - The displayed status in views, shows "calling" / "ongoing" only if the
      record is not older than 5 min / 4 hours. Otherwise it shows "ended
      unexpectedly" already (as if the cron already did its job), despite
      the record still having the "calling" / "ongoing" status.
    
    It is weird and non-perfect but this allows to not have a "heavy" cron
    job and consistent-enough call records display in views.
    
    Of course, the long-term plan is to have more reliable call records
    status (PBX, ...).
    
    A new problem related to this appeared though. Since [1], a call icon
    is used as the discuss presence icon in case the user is currently on a
    call. The "currently on a call" data being transferred based on a field
    "has_active_call" synchronized on call operations. Problem: in the case
    mentioned above (call stuck in ongoing), that field will stay wrong for
    a full month, showing the user as being on call. This commit makes it
    so the check for active calls now considers fresh-enough calls (just
    like the display in views does). It is only updated on a new call
    operation though, so if an user has a stuck call, he will still be shown
    as being on call until he starts/ends another call (or manually correct
    the stuck call record).
    Again, hopefully, stuck call records will be a thing of the past soon
    enough so that issue will be minimized.
    
    Note: this also uses `effective_start_date` instead of `start_date` to
    check for stale calls, as it handles the potential no start_date while
    ongoing that would stay stuck forever (that should not happen but,
    better safe than sorry).

[FIX] voip: not consider incoming calling calls for presence status
    
    Commit [1] introduced a "in-call" presence status. Commit [2], alongside
    several fixes (e.g. parents of this commit and mentioned commit),
    introduced new call demo data, including calling/ongoing calls:
    - One incoming calling for Mitchell Admin
    - One outgoing calling for Marc Demo
    - One incoming ongoing for Marc Demo
    - One outgoing ongoing for Marc Demo
    
    Consequence: both Mitchell Admin and Marc Demo always have the "in-call"
    presence icon, which might not be the best for demo. Still nice to test
    VoIP but misleading for the rest.
    
    In the end, we can have the best of both worlds: at the moment Mitchell
    Admin only has an incoming calling call... and actually, that kind of
    situation should not lead to being consider as "in-call". Calling
    someone does, but receiving a call that we are potentially ignoring at
    the moment does not.
    This commit makes it so incoming calling calls are not considered for
    presence anymore, at the same time thus making Mitchell Admin presence
    not impacted by default VoIP demo data.
    
[1] - https://github.com/odoo/enterprise/commit/f1e0c41fa7b4f425e45303e5e912bf093c56480a
[2] - https://github.com/odoo/enterprise/commit/f16faa029220ca7152289180c4de78783bab03be
    
task-6239844

### Steps to reproduce:
- Create a new WhatsApp account in Odoo
- Select a pre-generated draft WhatsApp template (one that has a multimedia file)
- Change the WhatsApp account of the template to the new account
- Click on "Submit for Approval" to upload a demo document
> TypeError: object of type 'LocalBinaryFile' has no len()

### Cause of Issue:
When uploading attachments via the requests library, `len()` is called on the file object to determine the Content-Length header and to handle chunked transfer encoding. The `LocalBinaryFile` class was missing a that method.

### Fix:
Added a `__len__()` method to the `LocalBinaryFile` class that returns `self.size`, which retrieves the file size from the `os.stat()` information already obtained during initialization. This allows the file size to be determined without loading the entire file into memory, maintaining the lazy-loading semantics of the class.

### Note:
This bug also affects all social media modules which rely on uploading attachments with the requests library.

opw-6272493

Steps to reproduce:
- Ensure you're not in dev mode(`--dev xml` disabled)
- Create ≈200 custom website snippets
- Go into website edit mode
- Traceback appears

Because of the high number of snippets, rendering the snippets templates exceeds the 1024-entry template cache limit. Earlier compiled templates are evicted from the LRU cache and may need to be processed a second time during the same render.

The second compilation reuses the etree stored in the transaction preload cache. As this etree was already consumed by the first compilation, the resulting output can contain empty snippet wrappers and crash the website editor.

This commit always copies preloaded etrees before compilation so the transaction cache retains a clean tree that can safely be processed again after an eviction.
A fix was already done for the same error in [1], where it was only done for dev mode.

opw-6230580
opw-6270833
opw-6276599

[1]: https://github.com/odoo/odoo/commit/f04a5cfee1a5c43824b04dec89712414b79e6cff

Forward-Port-Of: odoo/odoo#268550

Version:
---------
- saas-19.2+

Steps to reproduce:
-------------------

- Install `mrp` and `knowledge`
- Open Knowledge and create an article
- Add a clipboard block and write some text
- Go to Manufacturing → Operations → Manufacturing Orders
- Create a new Manufacturing Order
- Open the `Miscellaneous` tab
- In the `Additional Notes` field, click the Knowledge icon(Top right corner)
- Search and open the created article

Issue:
------
The Knowledge article does not display the
`Use As Additional Notes` action.

Cause:
------

The Knowledge clipboard integration detects compatible editable HTML fields
 from the active form view through `form_controller_patch.js`.

The detection first checks whether the field:
- is part of `KNOWLEDGE_RECORDED_FIELD_NAMES`,
- is an HTML field,
- and is writable.

```
The `note` field already satisfies the first condition: const KNOWLEDGE_RECORDED_FIELD_NAMES = [
    'note',
    'memo',
    'description',
];
```
However, the detection logic also filters out readonly fields:

```py
fields[name].type === "html" &&
!fields[name].readonly
```

In `mrp.production`, the `note` field is computed `Html` field:

```py
note = fields.Html(
    string="Additional Notes",
    compute='_compute_note',
    store=True,
)
```
Since computed fields are readonly by default unless explicitly marked
otherwise, Odoo exposes the field as readonly at the model level.

Even though the form view contains readonly Flase:

https://github.com/odoo/odoo/blob/9b9c72cc2c2ec0f7f5a74b39a11044b5f21f5d2e/addons/mrp/views/mrp_production_views.xml#L583

the Knowledge detection relies on the model field definition rather than
the view attribute. As a result, the `note` field is filtered out and
the clipboard action is never proposed.

 Fix:
-----

Mark the computed `note` field as writable by setting
`readonly=False` in the model definition.

This allows the Knowledge clipboard detection to recognize the field as
a valid editable HTML target and restores the
`Use As Additional Notes` action in Manufacturing Orders.

---

opw-6209675


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

Forward-Port-Of: odoo/odoo#266668

Version:
---------
- saas-19.2+

Steps to reproduce:
-------------------

- Install `mrp` and `knowledge`
- Open Knowledge and create an article
- Add a clipboard block and write some text
- Go to Manufacturing → Operations → Manufacturing Orders
- Create a new Manufacturing Order
- Open the `Miscellaneous` tab
- In the `Additional Notes` field, click the Knowledge icon(Top right corner)
- Search and open the created article

Issue:
------
The Knowledge article does not display the
`Use As Additional Notes` action.

Cause:
------

The Knowledge clipboard integration detects compatible editable HTML fields
 from the active form view through `form_controller_patch.js`.

The detection first checks whether the field:
- is part of `KNOWLEDGE_RECORDED_FIELD_NAMES`,
- is an HTML field,
- and is writable.

```
The `note` field already satisfies the first condition: const KNOWLEDGE_RECORDED_FIELD_NAMES = [
    'note',
    'memo',
    'description',
];
```
However, the detection logic also filters out readonly fields:

```py
fields[name].type === "html" &&
!fields[name].readonly
```

In `mrp.production`, the `note` field is computed `Html` field:

```py
note = fields.Html(
    string="Additional Notes",
    compute='_compute_note',
    store=True,
)
```
Since computed fields are readonly by default unless explicitly marked
otherwise, Odoo exposes the field as readonly at the model level.

Even though the form view contains readonly Flase:

https://github.com/odoo/odoo/blob/9b9c72cc2c2ec0f7f5a74b39a11044b5f21f5d2e/addons/mrp/views/mrp_production_views.xml#L583

the Knowledge detection relies on the model field definition rather than
the view attribute. As a result, the `note` field is filtered out and
the clipboard action is never proposed.

 Fix:
-----

Mark the computed `note` field as writable by setting
`readonly=False` in the model definition.

This allows the Knowledge clipboard detection to recognize the field as
a valid editable HTML target and restores the
`Use As Additional Notes` action in Manufacturing Orders.

---

opw-6209675


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

Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Forward-Port-Of: odoo/enterprise#119499
Forward-Port-Of: odoo/enterprise#113618

#### Description of the issue/feature this PR addresses:
In the Singapore localization (l10n_sg), reverse charge is modelled as a group tax pairing a -9% SRRC child with a +9% TXRC child, so the GST on a bill nets to zero while both legs are still reported in their respective GST return boxes. The child taxes "9% TXRC-TS" and "9% TXRC-ESS" shipped inactive, while their siblings "9% TXRC-N33" and "9% TXRC-RE" shipped active. Because children_tax_ids is a many2many onto account.tax (which has an active field), inactive children are filtered out of the group, so the groups "Reverse Charge - SRRC + TXRC-TS" and "Reverse Charge - SRRC + TXRC-ESS" only kept the -9% SRRC leg and computed a wrong GST amount, while leaving the +9% leg out of the GST return.

#### Current behavior before PR:
A vendor bill of S$10,000 taxed with "Reverse Charge - SRRC + TXRC-ESS" (or "+ TXRC-TS") shows 9% GST = -S$900.00 and a total of S$9,100.00 instead of net S$0.00 / S$10,000.00. The +9% TXRC leg never reaches Box 5 / Box 7 of the GST return. The sibling groups "+ TXRC-N33" and "+ TXRC-RE" are unaffected because their children are active. The only workaround is to manually activate the two child taxes.

#### Desired behavior after PR is merged:
The "9% TXRC-TS" and "9% TXRC-ESS" child taxes are active by default, so the group taxes aggregate both legs: a S$10,000 bill shows 9% GST = S$0.00 with a total of S$10,000.00, and both reverse charge legs land in their GST return boxes. New SG databases get this from the tax template; existing SG databases get the two taxes reactivated by a migration on upgrade.

opw-6199248

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

Forward-Port-Of: odoo/odoo#267670

Steps to reproduce:
- Ensure you're not in dev mode(`--dev xml` disabled)
- Create ≈200 custom website snippets
- Go into website edit mode
- Traceback appears

Because of the high number of snippets, rendering the snippets templates exceeds the 1024-entry template cache limit. Earlier compiled templates are evicted from the LRU cache and may need to be processed a second time during the same render.

The second compilation reuses the etree stored in the transaction preload cache. As this etree was already consumed by the first compilation, the resulting output can contain empty snippet wrappers and crash the website editor.

This commit always copies preloaded etrees before compilation so the transaction cache retains a clean tree that can safely be processed again after an eviction.
A fix was already done for the same error in [1], where it was only done for dev mode.

opw-6230580
opw-6270833
opw-6276599

[1]: https://github.com/odoo/odoo/commit/f04a5cfee1a5c43824b04dec89712414b79e6cff

Forward-Port-Of: odoo/odoo#268550

Before this fix:
The credit limit warning calculation only considered credit notes but ignored outstanding bank payments 
when computing the partner's effective outstanding balance. For example, if a customer had a credit limit
of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning 
would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the
actual outstanding amount was only 500.

After this fix:
The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases 
are handled:
- Bank payments received but not yet matched to any invoice, these are identified by their open suspense
  account entry and deducted from the partner's outstanding exposure.
- Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable
  line and deducted accordingly.

So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500
and does not show a warning since it is within the 1,000 credit limit.

task-5427613

Forward-Port-Of: odoo/enterprise#119785
Forward-Port-Of: odoo/enterprise#118957

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119597
Forward-Port-Of: odoo/enterprise#118759

#### Description of the issue/feature this PR addresses:
In the Singapore localization (l10n_sg), reverse charge is modelled as a group tax pairing a -9% SRRC child with a +9% TXRC child, so the GST on a bill nets to zero while both legs are still reported in their respective GST return boxes. The child taxes "9% TXRC-TS" and "9% TXRC-ESS" shipped inactive, while their siblings "9% TXRC-N33" and "9% TXRC-RE" shipped active. Because children_tax_ids is a many2many onto account.tax (which has an active field), inactive children are filtered out of the group, so the groups "Reverse Charge - SRRC + TXRC-TS" and "Reverse Charge - SRRC + TXRC-ESS" only kept the -9% SRRC leg and computed a wrong GST amount, while leaving the +9% leg out of the GST return.

#### Current behavior before PR:
A vendor bill of S$10,000 taxed with "Reverse Charge - SRRC + TXRC-ESS" (or "+ TXRC-TS") shows 9% GST = -S$900.00 and a total of S$9,100.00 instead of net S$0.00 / S$10,000.00. The +9% TXRC leg never reaches Box 5 / Box 7 of the GST return. The sibling groups "+ TXRC-N33" and "+ TXRC-RE" are unaffected because their children are active. The only workaround is to manually activate the two child taxes.

#### Desired behavior after PR is merged:
The "9% TXRC-TS" and "9% TXRC-ESS" child taxes are active by default, so the group taxes aggregate both legs: a S$10,000 bill shows 9% GST = S$0.00 with a total of S$10,000.00, and both reverse charge legs land in their GST return boxes. New SG databases get this from the tax template; existing SG databases get the two taxes reactivated by a migration on upgrade.

opw-6199248

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

Forward-Port-Of: odoo/odoo#267670

Summary
=======

`_check_if_used_in_website_form`, the ondelete hook on
`ir.model.fields` that guards against deleting a field referenced by
a website form, performs poorly on realistic databases. It can take
multiple minutes to validate a single field deletion, blocking user
actions such as removing a Studio field.

This commit restricts the scan to columns that can actually contain
website form markup, bringing the hook from multi-minute to
sub-second without any loss of coverage.

The Problem
===========

Deleting any `ir.model.fields` record triggers this validation hook,
which must ensure the field is not referenced inside any website
form. The implementation iterates every stored HTML column returned
by `website._get_html_fields()` and runs one case-insensitive
`ILIKE '%data-model_name="<model>"%'` search per column against
`<model>.<html_field>`, then parses each match with `lxml` and
validates it with XPath.

Two root issues cause the multi-minute cost:

- **Unbounded scan surface**: all stored HTML columns are scanned
  (~95 on realistic databases), even though the vast majority of them
  declare `sanitize=True` and `sanitize_form=True` (the defaults).
  When both flags are True, `<form>` tags are stripped on write and
  the column can never physically contain website form markup.
- **Per-column `ILIKE` cost**: `ILIKE` on large TEXT/JSONB columns
  performs a sequential scan. A single large HTML column is enough
  to make the hook run for several minutes on its own.

Improvements
============

- Scan only columns that can actually contain forms:
  - `ir.ui.view.arch_db` , primary target; all website forms are
    stored there.
  - HTML fields whose sanitization either is disabled
    (`sanitize=False`, e.g. `blog.post.content`,
    `website.custom_code_head`) or explicitly allows forms
    (`sanitize_form=False`, e.g.
    `product.template.website_description`, `hr.job.description`,
    `event.event.description`). Any other HTML field strips `<form>`
    on write and will never contain a form.
- Batch searches: group the deleted fields by model once and emit a
  single `OR`-domain search per candidate column, instead of one
  search per (field, column) pair.
- Parse each returned record with `lxml` and validate with XPath
  directly. The `ILIKE` domain already filters out non-matching rows
  DB-side.

Benchmarks
==========

Profiled on a database containing ~95 stored HTML columns and ~5.2k
views. The hook was invoked read-only via
`field._check_if_used_in_website_form()` on a custom field.

| Metric                         |     Before |      After |
| :----------------------------- | ---------: | ---------: |
| Hook wall time                 |     ~444 s |    ~173 ms |
| HTML columns scanned           |         95 |          5 |
| SQL queries issued             |         96 |          6 |

Key results:

- Hook wall time reduced from multi-minute to sub-second
  (~2,570× faster on the profiled database).
- Scan surface reduced from ~95 columns to a handful (1 +
  the form-capable HTML fields installed on the database, typically
  under 10).

opw-6086536

Forward-Port-Of: odoo/odoo#268666
Forward-Port-Of: odoo/odoo#259846

Steps to reproduce:
---
- Install `website_sale`.
- Create a product and from the Sales tab, add alternative products, making sure all products are published on the website.
- Open the main product on the website.
- In the alternative products section, open the editor, click the `brush` icon under `card design`.
- Under Actions > Buttons, click on the `cart` icon.
- Save the changes and click the `Add to Cart` button on an alternative product.

Issue:
---
- Clicking the `Add to Cart` button on alternative products does nothing.

Root cause:
---
- At [1], the `AddToCart` interaction uses the selector `.oe_website_sale button[name="add_to_cart"]` to find and attach click handlers. When the dynamic snippet renders alternative products, `startInteractions` is called on the `.dynamic_snippet_template` div. It searches for the button inside that div, but at [2], no element wrapping the button has the `oe_website_sale` class in the rendered product card template. So the selector matches nothing, and no click handler is attached.

Fix:
---
- Add `oe_website_sale` to the `o_wsale_product_btn` wrapper div in the product card template so the button becomes a descendant of `.oe_website_sale` within the injected content, allowing the interaction to attach correctly.

[1]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/static/src/interactions/add_to_cart.js#L5
[2]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L95-L113

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

Steps to reproduce:
- Ensure you're not in dev mode(`--dev xml` disabled)
- Create ≈200 custom website snippets
- Go into website edit mode
- Traceback appears

Because of the high number of snippets, rendering the snippets templates exceeds the 1024-entry template cache limit. Earlier compiled templates are evicted from the LRU cache and may need to be processed a second time during the same render.

The second compilation reuses the etree stored in the transaction preload cache. As this etree was already consumed by the first compilation, the resulting output can contain empty snippet wrappers and crash the website editor.

This commit always copies preloaded etrees before compilation so the transaction cache retains a clean tree that can safely be processed again after an eviction.
A fix was already done for the same error in [1], where it was only done for dev mode.

opw-6230580
opw-6270833
opw-6276599

[1]: https://github.com/odoo/odoo/commit/f04a5cfee1a5c43824b04dec89712414b79e6cff

Forward-Port-Of: odoo/odoo#268550

A product can have expiration date (use_expiration_date) enabled after being changed from lot/serial tracking to no tracking (quantity).

The issue this causes is that it can open the expiration popup since from saas-18.4 there is a line where if `ml.removal_date <= datetime.datetime.now()` the picking is expired.

So, if the product previously met these conditions, it will still be able to enter this flow.

And since this product doesn't use a lot_id it displays “You are going to deliver the product False, False which is expired or should at least be removed from stock”

What should happen:
When a product is not tracked, use_expiration_date should be False as expiration dates are intended to be managed through lots or serial numbers.

Steps to reproduce
1. Enable Product Expiry.
2. Create a storable product with:
- Tracking: By Lots
- Use Expiration Date: enabled
- Set a value greater than 0 for removal_time
3. Change the product tracking to By Quantity.
4. Create and validate a receipt for the product.

Related Tickets: opw-6255673

Forward-Port-Of: odoo/odoo#268135

**Steps to reproduce:**
1. Log in as a portal user.
2. Open a shared project and then open any task within it.
3. Observe the vertical spacing above the Follow/Unfollow button and the chatter 
component.

**Issue:**
The chatter UI has incorrect vertical spacing, causing elements like the
Follow/Unfollow button to sit too far down and appear misaligned.

**Cause:**
The pt-2 padding class was hardcoded in two separate locations: 
1. The compileChatter wrapper in project_sharing_form_compiler.js.
2. The portal.Chatter XML template.
When combined this caused a double-padding effect forcing excessive space.

**Fix:**
Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and 
the core XML template. This eliminates the double-padding conflict. This resolves 
the alignment issue in Project Sharing and does not affect the layout or 
functionality of other portal components.

task-4203362

Forward-Port-Of: odoo/odoo#268977
Forward-Port-Of: odoo/odoo#257490

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119517
Forward-Port-Of: odoo/enterprise#118759

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119517
Forward-Port-Of: odoo/enterprise#118759

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#102864

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#115256

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119517
Forward-Port-Of: odoo/enterprise#118759

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#102864

Issue
-----
Enabling signature requirement blocks US -> US deliveries.

Steps to reproduce
-----
- Setup UPS
	- enable signature requirement
- Set current company to US
- Create a US Customer
- Create a product with some weight
- Create a SO for the product
- Add UPS delivery and try to get a rate

> Error: "The requested accessory option is unavailable between the selected
locations."

Cause
-----
Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link)

https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US

US50 -> US50 & Canada -> Canada is package level
Everything else is shipment level

By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value.

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911

For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value

https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421

-----
Ticket:
opw-6173624

Forward-Port-Of: odoo/enterprise#117564

*=social_youtube,social_instagram,social_facebook,social_twitter, social_linkedin

**How to reproduce:**
- Open the Social Marketing feed.
- Click a Facebook, Instagram, or YouTube stream post with no comments.

**Issue:**
- A traceback is raised because the click handler tries to call `click()` on a missing comments element.
- The comments dialog does not open.

**Cause:**
- The kanban record click handler forwards clicks to `.o_social_comments`.
- For some media, the comments counter is not rendered when the post has zero comments.
- See: https://github.com/odoo/enterprise/commit/0293d3e839825a4333882e831960050070b02ba6

**Fix:**
- Make the shared handler detect when the comments element is missing.
- Delegate that case to media-specific handlers so Facebook, Instagram, and YouTube can open their comments dialog directly.
- This commit also hides the X and LinkedIn comments counters when there are no comments, aligning them with the other social media cards.

Task-6113089

Forward-Port-Of: odoo/enterprise#118006

Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting.

* Introduce dedicated work entry types for:

  * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81)
  * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1)
* Add salary rules and categories for voluntary overtime remuneration.
* Enforce yearly thresholds through payroll parameters:

  * 240h for voluntary overtime exempt from ONSS
  * 120h for voluntary overtime subject to ONSS
* Exclude voluntary overtime from employment bonus calculations and paid amount computation where required.
* Include voluntary overtime remuneration in payroll calculations and DMFA declarations.
* Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields.
* Fix DMFA service hour computation and add payroll/DMFA test coverage.

TaskID: 6275791

Forward-Port-Of: odoo/enterprise#119355

Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

Forward-Port-Of: odoo/enterprise#119640
Forward-Port-Of: odoo/enterprise#115409

### Steps to Reproduce:
1. Have 2 companies (Company A and Company B)
2. Create a global product (visible in both companies)
3. in Company A, for the product BOM make it a normal type ("Manufacture this product") with a couple components, each with 0 units in this company.
4. Set the product to have quantity 50 units in Company A
5. In Company B, for the product BOM make it a phantom type ("Kit") with one component, 100 units so there are 100 units of the product in Company B too.
6. Now only select Company A and on the product page, set the cost to any nonzero amount.
7. Go to Inventory > Reporting > Stock, and see how the quants are all 0. however, if you click into the product page, the on hand quantity SmartButton says 50

### Description of the issue/feature this PR addresses: 
**Issue:** When stock valuation logic does a compute_value in superuser mode, the _bom_find method ignores multi-company record rules. This causes the search to find kits from other companies, leading to incorrect quantity computations.

**Solution:** Force the env to drop the superuser flag (su=False) specifically during the BoM search. This ensures the ORM applies standard ir.rule filters, and isolates BoM results to the current company context.

### Current behavior before PR:
In superuser mode, the BoM search is company-blind and returns the first matching kit found in the entire database. If a kit is found in a different company, the stock report incorrectly explodes the kits and looks for the components in the current company's warehouse.

### Desired behavior after PR is merged:
The BoM search should respect multi-company isolation so the system will only identify a product as a kit if a valid BoM exists within the user's active company or the global context.

opw-6170112

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

Before this commit, sometimes an overlay such as Dialog could flicker and render twice on mount.

This comes from implementation details for detecting whether the overlay comes from shadow DOM or website, to determine which overlay container should decide to display the overlay [1]. The code relies on presence of the root id in the DOM and overlay container was relying on presence of `ref.el` to get the root id from DOM. This was motivated by `isVisible(overlay)` whose computation was also relying on the ref [2] but this has the drawback that `ref.el` was sometimes not yet available immediately on 1st rendering. Solution of [1] was to re-renderer whenever `ref.el` is set, but another solution that prevents a re-render is to have the root id in the `env`.

This commit changes the solution of [1] by instead `rootId` in the `env`. The new solution has the benefit to not require a re-render of the overlay container, which prevents undesirable flickers that may happen on mounting an overlay for the 1st time.

[1]: https://github.com/odoo/odoo/pull/169264
[2]: https://github.com/odoo/odoo/pull/154349

Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

**Description of the issue/feature this PR addresses:**

When generating a SEPA QR code for a vendor bill payment, the embedded 
amount could occasionally contain excess decimal places instead of 
respecting the currency's expected precision.

This occurs because the `amount` variable in `_get_qr_vals` was being 
converted directly using `str(amount)`. Due to Python's floating-point 
arithmetic, the float value in memory can contain decimal drift.
Directly casting it to a string exposes this drift in the payload.

This commit resolves the issue by replacing `str(amount)` with 
`float_repr(amount, currency.decimal_places)`. This safely bypasses 
the float representation issue, ensuring the string strictly respects 
the currency's configured decimal precision before being injected 
into the QR code.

opw-5504258

**Steps to reproduce:**

- Select company “My Belgian Company”
- Create a 23% purchase tax
- Create vendor bill
   - Select Vendor “BE Company CoA”
   - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73
   - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show

**Current behavior before PR:**

- When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift.

**Desired behavior after PR is merged:**

- The SEPA QR code is generated with the correct number of decimal places.

## The Problem
When grouping messages, the code was accumulating recordsets using the `|=` union operator inside a loop. Since each union call internally builds an `OrderedSet` over all previously accumulated IDs, the performance degraded quadratically relative to the number of document records. This caused bottlenecks on databases with large message volumes.

## The Solution
* Replaced the `|=` recordset accumulation with a plain Python dictionary of ordered sets to store IDs per operation, while keeping same behavior.
* Deferred the `browse()` call until after the loop is complete.
* Reduced the overall complexity from **$O(N^2)$** to **$O(N)$**.

---

## Benchmarks
*Tested on a customer database grouping by "Created By" and "Created On":*

| Record Count | Before | After | Improvement |
| :--- | :--- | :--- | :--- |
| **300k records** | 83.00s | **1.00s** | **-99%** |
| **30k records** | 0.60s | 0.25s | (Minor) |

**Note:** The performance gains become exponentially more significant as the record count grows.

**OPW-6123758**