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

Problem: When opening the Studio XML editor when Website is installed, the
translation terms corresponding to the Default Language of the first
website in the database are used. This behavior should only be applied
to the HTML/CSS Editor in Website.

Purpose: Modify Website's override of get_related_views to only return
translated views when called with a specific website in context.
This is done here by adding a context flag, as to not interfere with
customizations made in stable versions. This will be changed for master.

Steps to Reproduce in Runbot:

1. Activate a non-English (US) language.
2. Add this language to the Website with the lowest ID in the database,
then set it to the Default Language of the Website.
3. While in debug mode, enter Studio and navigate to a view that has
   translation terms (ex. Sale Order Form view), then open the XML
editor.

opw-5136124

Foward Port of https://github.com/odoo/enterprise/pull/110418

Forward-Port-Of: odoo/enterprise#116771

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

### Steps to reproduce:
- Download 'Sales' and 'Timesheets' apps
- Create a service product invoiced on delivered quantities with timesheet tracking
- Create and confirm a SO for quantity 1
- Log 20h on timesheets
- Invoice the SO
- Create a credit note for 11 hours => only 9 hours are invoiced
- Log 5h more on timesheets
- Back to the SO > create invoice again
> All the 25hrs are to invoiced, although 9 of them were invoiced before

### Cause of Issue:
When generating the new invoice, `_recompute_qty_to_invoice` calls `_get_delivered_quantity_by_analytic` which retrieves the analytic values for the SO line.

The values retrieved are later used to determine the delivered quantity, which is later assigned to be `line.qty_to_invoice` without taking into account the already invoiced hours. https://github.com/odoo/odoo/blob/7a6518e39d34575a3977e7c4a0053a45223e203c/addons/sale_timesheet/models/sale_order_line.py#L176-L186

### Fix:
Ensures that hours that have already been completely invoiced are deducted from the quantity to invoice.

opw-6253650

Forward-Port-Of: odoo/odoo#274035
Forward-Port-Of: odoo/odoo#268025

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

Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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

Forward-Port-Of: odoo/odoo#273570
Forward-Port-Of: odoo/odoo#273010

When a customer paid through DPO, they landed on the DPO error page ("Not Valid - this transaction is no longer valid") instead of the payment page, even though the transaction token was created correctly.

The customer is redirected to `https://secure.3gdirectpay.com/payv2.php` with the transaction token passed as the `ID` parameter. `payv2.php` answers with a 302 redirect to `payv3.php`. Per HTTP semantics, a 302 turns the request into a GET and drops the body, so when `ID` is sent in the body of a POST it never reaches `payv3.php`: the customer arrives at `payv3.php?` with no token and DPO rejects it as invalid.

This regressed with 97ec8a3e72d9d48a0a9620c53feea533421b9d67, which moved redirect providers to the generic redirect form. Before that commit, the token was part of the action URL itself (`payv2.php?ID=<token>`), so it stayed in the query string across the redirect. The refactor moved `ID` into `url_params` rendered as a hidden input, and since `http_method` was left unset the generic form defaults to POST, putting `ID` in the body.

Set `http_method` to "get" so the token is serialized back into the query string and survives the `payv2.php` -> `payv3.php` redirect, restoring the pre-refactor behavior. This also matches DPO's documented convention of passing the token in the URL query string.

opw-6312732

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

When Google sends an all-day event, the payload only contains a date (no time), so the inbound sync stores start and stop at 00:00 UTC. The list view renders those Datetime fields in the viewing user's timezone, so any user west of UTC sees the previous day. The calendar view stays correct because it reads the date part directly.

The rest of Odoo stores all-day events at 08:00 and 18:00 UTC, which keeps the stored datetime inside the same calendar day:
https://github.com/odoo/odoo/blob/327ad9b737b0f1d4c547c71a52c45d8433f2b3f4/addons/calendar/models/calendar_event.py#L408-L414

Apply the same 08:00 / 18:00 normalization when building values from a Google all-day payload, so events created on Google match events created in Odoo.

Steps to reproduce:
1. Set your user timezone to America/Winnipeg.
2. Connect a Google account and run the calendar sync.
3. In Google Calendar, create an all-day event on January 31.
4. Sync, then open Calendar in list view in Odoo.

=> Start Date and End Date columns show January 30.

Ticket [link](https://www.odoo.com/odoo/project.task/6145880)
opw-6145880

Forward-Port-Of: odoo/odoo#271573
Forward-Port-Of: odoo/odoo#262282

This PR improves the cost of `/forum/my-forum-1/my-slug-1234` by ~48%.

This has a huge impact on odoo.com

The `/forum/...` routes are the `#1` on odoo.com in terms of absolute count and in terms of CPU and SQL cost. They are called several million times a day. 

The average total time for `/forum/my-forum-1/my-slug-1234` goes from ~358ms to ~187ms (sql: 107ms -> 52ms - cpu 250ms -> 135ms)

This has been tested by extracting 30k real forum post urls from odoo.com logs and replaying them on a staging server. That day `/forum/...` routes were called 2.8M times

## before
<img width="1343" height="122" alt="image" src="https://github.com/user-attachments/assets/2b8264b7-4f26-40a7-a20a-20d478f5a93a" />

## after
<img width="1339" height="124" alt="image" src="https://github.com/user-attachments/assets/7c73aeb0-a4b4-45b8-ae98-093ac70c438e" />



### First commit

before
<img width="1857" height="946" alt="image" src="https://github.com/user-attachments/assets/63b9d966-f5fd-4047-b4cb-533b7e9491bc" />


after

<img width="1844" height="867" alt="image" src="https://github.com/user-attachments/assets/9494efe0-0b7c-419d-b918-dcfe5e942e63" />


query plan for most used tags as public user:

- with the index https://explain.dalibo.com/plan/gbf9fbd358687f3e
- without the index https://explain.dalibo.com/plan/da5gg6cd27f67496

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

Before this commit, joining a call in a mobile browser (Chrome, Safari, ...) would crop the bottom call controls (mic, camera, hang-up, ...) behind the browser's chrome (URL bar / bottom nav).

On mobile, entering the meeting uses the fullscreen overlay with `keepBrowserHeader: true`, so no native fullscreen is requested and the browser UI stays visible. The overlay was sized with the Bootstrap `vh-100` class (`height: 100vh`), and `100vh` resolves to the *large* viewport (as if the URL bar were hidden). Combined with `fixed-top`, the overlay extended past the visible area and pushed the control row off screen.

This commit sizes the overlay with `100dvh` (dynamic viewport height) instead, which tracks the currently visible viewport and shrinks while the URL bar is shown, keeping the controls on screen. This is a no-op in native/desktop fullscreen where `dvh == vh`, and matches the `dvh` usage already present in the codebase (welcome page, bottom sheet).

task-6353266


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

Forward-Port-Of: odoo/odoo#273949

Since 17.0, `webp` images can be uploaded at any resolution, whereas every other format is refused above IMAGE_MAX_RESOLUTION (50 Mpx) when the attachment is created on the server.

Root cause
===========
`ImageProcess` grouped webp together with empty sources and SVG and set `self.image = False`, returning before the `verify_resolution` check. As a result the resolution limit enforced for `png/jpeg/...` was never applied to `webp`.

Fix
===
Split `webp` out of the skip branch: it is still not processed as before, but its resolution is now read from the RIFF header with `get_webp_size()` and checked against `IMAGE_MAX_RESOLUTION`, so oversized webp images are refused on upload like any other format.

Steps to reproduce
===================
1. Edit any page with the website editor
2. Upload a `webp` image larger than 50 Mpx (e.g. 8000x8000)

=> The image is accepted, while a `png/jpeg` of the same size is refused

task-4134430

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

Forward-Port-Of: odoo/odoo#273570
Forward-Port-Of: odoo/odoo#273010

When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created.

Steps to reproduce:
1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local).
3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day).
4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar.

opw-6024835

Forward-Port-Of: odoo/odoo#273915
Forward-Port-Of: odoo/odoo#265297

Before this PR
---
- Projects created from the kanban quick create have no company at creation
  time, so their workspace is born without one. Changing the company later
  from the form view was silently ignored for the workspace, causing the
  workspace and its documents to remain without a company.
- Projects created from the list view had their company set at creation, so
  their workspace already had a company, and changes were correctly propagated.
  This inconsistency made the behavior depend on how the project was created.

After this PR
---
- When a project's company changes, all projects linked to the same workspace
  are checked:
  - If all linked projects are now in the same company, the workspace company
    is updated accordingly.
  - If linked projects are in different companies and the workspace has no
    company, the workspace is left untouched (accessible to all companies).
  - If linked projects are in different companies and the workspace already has
    a company, an error is raised (existing behavior, unchanged).
- This makes the behavior consistent regardless of how the project was created
  (kanban quick create or list view).

task-4988098

Replaced `useLayoutEffect` in `InnerGroupItemComponent` with `onMounted` +
`onPatched` because `useLayoutEffect` is deprecated in OWL3.

The single effect decorated label/field DOM elements with studio CSS classes
immediately after each render. A reactive `useEffect` (OWL3's signal-based
scheduler) re-runs asynchronously, so `studio_view.updateActiveNode` — which
reads `.o-web-studio-editor--element-clickable` via `el.closest()` right after
the view re-renders — found the label without the class, and the
`o-web-studio-editor--element-clicked` decoration was never applied.
`onMounted` + `onPatched` run synchronously within the patch commit, matching
the timing the compat `useLayoutEffect` provided (which is itself implemented
via `onMounted`/`onPatched`).

`labelRef` and `fieldRef` were converted from OWL2 compat `useRef` wrappers to
plain `signal(null)` class fields so the template uses `t-ref="this.labelRef"`
/ `t-ref="this.fieldRef"` and the refs are read with `this.labelRef()` /
`this.fieldRef()` inside `applyStudioClasses`. The unrelated `rootRef` in
`OuterGroup`/`InnerGroup` is kept as `useRef` since those classes have not been
migrated.

The useLayoutEffect refactored in this PR had test coverage — below are some
tests that failed when the effect was commented out, and are now passing:
- @web_studio/view_editors/form_editor/move a field in form
- @web_studio/view_editors/form_editor/correctly display hook below group title
- @web_studio/view_editors/interactive_editor_sidebar/update sidebar after edition
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2602198/build/115250548

Replaced `useLayoutEffect` with `onWillRender` + `onMounted` + `onPatched`
because `useLayoutEffect` is deprecated in OWL3.

`useEffect` was tried first but its microtask-deferred re-runs are decoupled
from the render/patch cycle. On softphone reopen (hide → systray click), the
batched re-run arrived after the click already set `isDisplayed = true`, so
the effect read the already-true flag and called `hide()` a second time —
leaving the softphone closed and the search-bar input unfocused. The fix
reproduces the original render-coupled timing with three native hooks:
`onWillRender` subscribes the component to the reactive proxy so state
changes trigger re-renders; `onMounted` applies the initial show/hide/promote
logic; `onPatched` applies it on every subsequent render — matching the
behaviour of the original `useLayoutEffect` exactly.

The useLayoutEffect refactored in this PR had test coverage — below are some
tests that failed when the effect was commented out, and are now passing:
- @voip/softphone/softphone/Opening the softphone selects the Recent tab.
- @voip/softphone/softphone/Search bar is focused after reopen the softphone.
- @voip/softphone/activity_tab/Call activities are displayed in the "Activities" tab.
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2596849/build/114857981

Replaced `useLayoutEffect` in `FormControllerPatch.setup()` with `onMounted`/`onPatched` because `useLayoutEffect` is deprecated in OWL3.

`useLayoutEffect` ran post-mount, after the chatter had registered its `__knowledgeUpdateCommandsRecordInfo__` callback. `useEffect` ran during `setup`, before the chatter was ready, so chatter access rights were never recorded. `onMounted`/`onPatched` with a `lastResId` guard restores the original post-mount timing and only re-evaluates on record navigation.

The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- TestKnowledgeEditorCommands.test_knowledge_article_commands_tour
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_file_as_attachment_from_knowledge
- TestHelpdeskKnowledgeCrossModuleFeatures.test_helpdesk_pick_template_as_description_from_knowledge
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2604778/build/115379873

Replaced `useLayoutEffect` with `onMounted` + `onPatched` because `useLayoutEffect` is deprecated in OWL3.

The single tracked dependency was `component.props.reactive.cell` — a reactive property holding the cell's HTMLElement (or null). The effect body wrote `component.state.cell` and immediately re-read it (via `state.cell.row.isSection` and `component.isEditable()`). A native OWL3 `useEffect` subscription was tried first but failed: the signal effect runs eagerly during `setup()`, before mount, so `rootRef.el` is null on the first run when `props.reactive.cell` is truthy, crashing with `Cannot read properties of null (reading 'style')`. Since the component already re-renders whenever `reactive.cell` changes (the overlay root is `<div t-if="props.reactive.cell">`), plain `onMounted` + `onPatched` running the same body is sufficient: `rootRef.el` is guaranteed present whenever `cellEl` is truthy, no `untrack` is needed, and the lifecycle callbacks reproduce the original post-render timing exactly.

The use of `useLayoutEffect` refactored in this PR had test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- @web_grid/grid_view/grid_view_desktop/editing a value
- @web_grid/grid_cells/float_toggle_grid_cell/FloatToggleGridCell: click to focus
- @web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624597/build/116553714

When a Knowledge article embeds a kanban, calendar or map view and the user prints it or exports it to PDF, the view is missing and the printed page is blank.

The Knowledge print stylesheet hides those embedded views in print mode. The rule was introduced with the print feature under the selector `.o_knowledge_embedded_view > .o_kanban_view`, but `.o_knowledge_embedded_view` is emitted nowhere in the templates or components, so the rule matched nothing and the embedded views were always printed. Commit https://github.com/odoo/enterprise/commit/69612c80ea0aec5ccf2c2857449da03e61273457 rescoped the print rules and retargeted the selector to the real wrapper as `[data-embedded="view"] .o_kanban_view`. That selector matches, so the views are now hidden and the printed article is blank.

Remove the rule from `knowledge_print.scss` so embedded views render again in print mode, restoring the behavior that held since the print feature was introduced.

Steps to reproduce:
1. Open Knowledge and create a new article.
2. Click Build an Item Kanban, type a name and click Insert.
3. Add an item with Quick add so a card appears in the kanban.
4. Open the article options menu and click Download PDF.

=> The embedded kanban view is missing and the PDF is blank.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6299703)
opw-6299703

Currently when a shopfloor operator modifies the operator, operator images are not visible and only place holder images are visible.

## Steps to produce:
- Install Manufacturing with demo data
- Login as Marc Demo
- Open shopfloor

## Observed Behavior:
Operator is unable to see their own profile picture and when you press the Edit Operator the operator is not able to see their as well as other operators images as well.

## Root cause:
This issue occurs because by default an operator's user does not have access right for `Employees` in Human Resources section as they are not an HR officer nor an administrator.

So when the user tries to access the image url that is meant for users with those access rights (HR officer / Administrator) at [1] and at [2].

The system returns a placeholder image instead of the employee image since the operator does not have access to hr employee model but does have access to hr employee public as per this [commit](https://github.com/odoo/odoo/commit/c9ca3761464413327d2beb697553a3ccd7eef4d1)

[1]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/dialog/mrp_employee_dialog.js#L16 
[2]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/employees_panel.xml#L9-L10 

## Solution:
Allowing operators to see images can be done by modifying the links to use the public model instead of the private model.

This will allow operators see other operators based on images and should improve user experience.

| Before |
|--------|
| <img width="1865" height="844" alt="image" src="https://github.com/user-attachments/assets/c28f4209-0a60-486a-bfec-2a4db39cd946" /> |
| <img width="995" height="899" alt="image" src="https://github.com/user-attachments/assets/7541edd9-6cc9-42d1-b5c5-39e0740d9a93" /> | 

| After |
|--------|
| <img width="1881" height="903" alt="image" src="https://github.com/user-attachments/assets/df3f8357-5cc2-4688-83dd-9a009fd56957" /> |
| <img width="1221" height="862" alt="image" src="https://github.com/user-attachments/assets/c9d72b07-e1ad-43e4-85f5-00d8f1db9095" /> | 



opw-6321989

Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916

Forward-Port-Of: odoo/enterprise#119542

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:
    - When the attendance is flexible, the weekly expected hours shown in reports are incorrect.
    - This happens because the calculation is based only on the `Average Hour per Day` and doesn't take into account the `Hours per Week` set on the employee resource. It ignores the weekly limit defined in the employee's working schedule. -As a result, if an employee works more days than expected, the report may show more than the allowed weekly hours.

    Example:
    - An employee has a 32h/week contract and 8h/day.
    - If they work 5 days, the system still counts 8h as expected for each day — totaling 40h instead of 32h.

Steps To reporduce:
    - Set up a flexible contract with 32 hours/week (8 hours/day) for an employee.
    - Log 5 attendances in one week with 8 worked hours each.
    - Go to report and filter by employee by week, notice the current behavior yields 5 x 8 = 40 hours in expected_hours.

Solution:
    - Check the weekly hours cap defined in `resource_calendar_id.full_time_required_hours`.
    - If total `expected_hours` from earlier attendances this week exceeds that limit, set expected_hours = 0 for any excess.

OPW-4583064

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

Description of the issue/feature this PR addresses:
When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`.

In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views.

Current behavior before PR:
A datetime value in the afternoon is grouped under a 12-hour label without AM/PM.

For example, records around `13:50` are displayed under:

    01:00 20 Mar

Similarly, a datetime value around `16:20` may be grouped under:

    04:00 26 Mar

This is ambiguous because the group header does not indicate whether the hour is AM or PM.

Example screenshot showing records around 13:xx grouped under `01:00`:
<img width="251" height="195" alt="image" src="https://github.com/user-attachments/assets/9c394063-f679-4faa-a045-2456cc452fb9" />


Desired behavior after PR is merged:
Hour-based datetime group labels should be unambiguous.

The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock.

For example:

    13:00 20 Mar
    16:00 26 Mar

This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers.

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

The following use case has been observed:

0. Customer start a payment from /shop/payment.
1. We received the webhook that notifies that the payment succeeded.
2. The payment post-processing cron start (it gather all the transactions that need to be processed, including the customer new transaction)
3. Meanwhile, the customer is redirected back by the payment provider to Odoo, which then redirect to /payment/status and start the payment post-processing for that specific transaction
4. The customer initiated payment processing finishes, he is redirected back to /my/orders/... page.
5. The payment post-processing cron finally start processing the same customer transaction and process it (a second time).

In that case, as the transactions to be post-processed backlog was quite high, there is consequent time between the time we gather all the TXs to post-process and actually process the customer transaction.

Also we don't end up with a `SerializationError` as the cron do commit after each transaction post-processing.

This commit force invalidate individual transaction cache values and recheck if it effectively still need to be post-processed before doing it.

opw-6332192

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