### Steps to reproduce

1. Configure UrbanPiper and start a POS session.
2. Receive an order from the delivery provider.
3. Accept the order and mark it as **Ready**.
4. Cancel the order from the delivery provider.
5. Reopen the running POS session.

### Current behavior

When a delivery provider cancels an order, the `delivery_status` is updated to `cancelled`, while the POS order state remains (`draft`, `paid`, or `done`).

As a result:

* Cancelled deliveries are still included in the active delivery order count.
* `_get_urbanpiper_order_count()` attempts to map the `cancelled` status, which is not present in `status_map`, raising a `KeyError`.
* The POS UI fails to load, preventing users from reopening the running session.

### Expected behavior

Cancelled delivery orders should not be considered active delivery orders and should not be included in the delivery status count, allowing the POS session to open normally.

### Solution

Exclude orders with `delivery_status = 'cancelled'` from the active delivery order count computation. This prevents the `KeyError` and ensures cancelled delivery orders are ignored when computing active delivery statistics.

[Video reproducing the issue](https://drive.google.com/file/d/1XdiylekWV-q6LTbvhCgbyd_KDKlG2imz/view?usp=sharing)

---

**opw-6353861**

Forward-Port-Of: odoo/enterprise#122798

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/enterprise#121940
Forward-Port-Of: odoo/enterprise#119530

**Steps to Reproduce:**
1)Create a database in v19.2.
2)Install the l10n_be_hr_payroll module.
3)Open the login user's profile and set the Payroll access rights to No (null).
4)Navigate to Employees → Configuration → Working Schedules.

**Actual Result:**
A traceback is triggered after opening the record.

```python
Failed to read field resource.calendar.l10n_be_reorganisation_measure_ids
You are not allowed to access 'BE: Reorganisation Measure.'
(l10n.be.reorganisation.measure) records.

This operation is allowed for the following groups:
	- Payroll/Assistant

Contact your administrator to request access if necessary.
```

**Issue:-**
The traceback is caused by the following commit introduced in v19.2 [here](https://github.com/odoo/enterprise/commit/e1092393ff99e9dad84ea8b9d6066e0bc61d6312) In this commit, a new computed field `l10n_be_reorganisation_measure_ids` was added on `resource.calendar`. The field is computed and store=true when the read function is called, and reads the data from the database at that time; The payroll doesn't have any access rights due to the error

**Solution:**
To fix this issue, a group access check is added inside the field

Ticket:- 6245936

Forward-Port-Of: odoo/enterprise#119518

Consider two models like this:
 - model A has fields `base`, `total` and `line_ids` (to model B);
 - model B has fields `price` and `subtotal`.

Field `subtotal` depends on `base`, and field `total` depends on `line_ids.subtotal`, but does not use it in its compute method.

The second time `base` is modified in a form view, method `onchange()` is sent the values of `base`, `total` and `line_ids` (with the former update of `subtotal`).  When putting field `line_ids` in cache, field `subtotal` invalidates field `total` on the main record.  This causes field `total` to be recomputed too soon, which eventually prevents `onchange()` from detecting that `total` has changed.  The form view ends up with an incorrect value of `total`.

The fix consists in setting field `subtotal` in cache without triggering recomputation of dependent fields.  The error actually lies in method `convert_to_cache()` of x2many fields, specifically in the way to handle UPDATE commands.  It should update the corresponding record's cache instead of assigning its fields.

When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback.

Steps to reproduce the error:
- Install ``hr_recruitment`` module with demo data
- Go to Recruitment > Applications > Talent Pools > Create a new pool
- Go to Recruitment > Applications > All Applications > Create a new application with valid email >
  Click Add to Pool > Select the Talent Pool > Add to Pool
- Duplicate the created talent record
- Create another application with the same email > save > click Talent Pools

Traceback:
```py
ValueError: Expected singleton: hr.applicant(2, 1)
```

https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859
Here, the talent is searched using matching applicant information.
When a matching talent has been duplicated, the search returns multiple records.
Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error.

Solution:
Restrict the duplication of talent.

sentry-7556261128

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

Forward-Port-Of: odoo/odoo#273565
Forward-Port-Of: odoo/odoo#270827

*: [html_builder, mass_mailing]

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

- The resize handle SCSS used `border-left/right` on `.col-*` elements which adds real pixels to the box model, shifting column content to the right even when the border was transparent.

- The column resize mechanism (hover detection + drag) was active in website and mass_mailing, conflicting with their own resize handle indicators.

- Website and mass_mailing live inside an outer `.container` which provides Bootstrap gutter padding (`--gutter-x`). The border on top of that made the shift layout.

### Desired behavior after PR is merged:

- Replace `border` with `box-shadow: inset` for the resize handle indicator. `box-shadow` is visual and takes zero space in the box model, so content alignment is preserved.

- Style scope to body:not(.editor_enable) .odoo-editor-editable .o_text_columns
`body:not(.editor_enable)` excludes the builder editor context. Website and mass_mailing rely on Bootstrap classes for their column layout.

- Add `allowTextColumnResize` config flag (default: `true`) in `ColumnPlugin`. Website and mass_mailing set it to `false` to disable the `ResizePlugin` column parameters, preventing conflicts with their own resize handles.

task-6233558

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

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/odoo#272487
Forward-Port-Of: odoo/odoo#268527

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

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

Forward-Port-Of: odoo/odoo#273119
Forward-Port-Of: odoo/odoo#271864

In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.

### Steps to reproduce

1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
   - `Website A` on the main company, domain `http://website-a.test`
   - `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.

### Cause

Mass mailing builds the unsubscribe link in two steps.

First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.

Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.

The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.

### Fix

Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.

opw-4914203

Forward-Port-Of: odoo/odoo#274191
Forward-Port-Of: odoo/odoo#264055