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

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

Steps to reproduce:
-------------------------------------------
1. Install the Timesheet module with demo data
2. Go to any FSM task > set allocated hours to 20h
3. Fill the timesheet for the same task for 10h
4. Navigate to FSM > My Tasks > Gantt view

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />


After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />


opw-6038983

Forward-Port-Of: odoo/enterprise#122899
Forward-Port-Of: odoo/enterprise#111270

**Issue**
Having supplier pricelists with at least one vendor inaccessible to the current user can trigger an access error when creating an RFQ approval request.

**Steps to reproduce**
- Have two companies A and B and two users u1 and u2
- user u2 only have access to company A
- With user u1:
	- Create two vendors v1 and v2 without any company assigned
	- Create vendor pricelists for a product for each vendor and assign the company A to the pricelist
- Add the company B for the vendor v2
- With user u2:
	- Open approval application
	- Try to create an approval for an RFQ for that product (the vendor v1 will be automatically selected)
	- Save it -> An access error is thrown

**Cause**
Saving the approval request computes `has_no_seller`, which calls `_select_seller`: https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/views/approval_product_line_views.xml#L9 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L32 https://github.com/odoo/enterprise/blob/03c737685ff6dfc95a8bc72491646774fc426b1f/approvals_purchase/models/approval_product_line.py#L62-L70 
Which filtered the right seller
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L759 
By preparing the sellers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L721 https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_product.py#L712 
Please note that `self.seller_ids` contains both sellers (even v2) By filtering the suppliers:
https://github.com/odoo/odoo/blob/c37e76850d3ff790b76493bd1003d80e170bd4bf/addons/product/models/product_supplierinfo.py#L104-L105 
But at that point, one of the supplier in `self`, can be accessed, thus an access error is thrown while trying to access its associated `partner_id`.

opw-6203910

Forward-Port-Of: odoo/enterprise#121008
Forward-Port-Of: odoo/enterprise#120251

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

Forward-Port-Of: odoo/enterprise#122994
Forward-Port-Of: odoo/enterprise#122297