Steps to reproduce:
1. Create a log note or send a message on any record and open the full composer.
2. Set a date in the future to schedule the message for later and click schedule.
3. Click on the "Edit" button of the newly scheduled message.
4. Try dragging and dropping an image into the body, or add a file as an attachment using the button.

Issue:
- Dragging and dropping an image into the form does nothing.
- Trying to add a file as an attachment using the button triggers a traceback: `TypeError: Cannot read properties of undefined (reading 'resId')`

Why this happens:
- The failure when adding explicit file attachments occurs because the `model` and `res_id` fields were omitted from the `mail.scheduled.message` form view layout in the commit 3b985d2. Without these field  declarations, the `mail_composer_attachment_selector` widget cannot determine the record metadata parameters, causing the upload to crash.
- The failure of the drag-and-drop mechanism occurs because the scheduled message edit view uses the default `FormController` class instead of `MailComposerFormController` which is used in the `mail_compose_message` view. Consequently, the underlying `useCustomDropzone` is never instantiated on the view, leaving drop events unhandled.

Fix:
1. Specify `js_class="mail_composer_form"` to the scheduled message form view definition tag to handle drag and drop, as well as adding the missing fields
2. Assign the `resIds` variable based on the message type since it is defined as `res_id` instead of `res_ids` in `mail.scheduled.message`.

opw-6273260

Forward-Port-Of: odoo/odoo#268515

**Issue:** Installing `l10n_uy` on a demo database raises a ValidationError from the `check_use_document` constraint since 19.3+. The error occurs because `ir_module.py:write()` re-applies module-specific template data to all companies with a matching chart template after installation. At that point, `demo_company_uy` already exists with `chart_template='uy'` and posted demo invoices, so `_load_data` ends up writing `l10n_latam_use_documents=True` to a journal that has validated entries.

This write was previously suppressed by `_pre_reload_data`, which unconditionally removed journals from the data when found by xmlid. Commit 056b8e38ff84 (saas-19.3) narrowed that protection to only apply when `'type' in journal_data`. Since the module-filtered data never includes `type` (that field comes from `_get_account_journal` in the base `account` module, excluded by the module filter), the journal is no longer protected and the write triggers the constraint.

**Versions:** 19.3+

**Fix:** remove `l10n_latam_use_documents=True` from `_get_uy_account_journal`. `l10n_latam_invoice_document` already sets this field for all LATAM companies via `_get_latam_document_account_journal`; l10n_uy was setting it redundantly.

Task id: [6354499](https://www.odoo.com/odoo/project/49/tasks/6354499)

Forward-Port-Of: odoo/odoo#273930

Steps to reproduce:
- Add the "Supported Payment Methods" snippet on a website page
- Open the page as a public (non-logged-in) visitor => An AccessError is raised: "You are not allowed to access 'Payment
   Method' (payment.method) records".

`get_supported_payment_methods` searched `payment.method` without `sudo()`, and its JSON response embeds `image` URLs that are fetched by the browser through the public `/web/image` controller, which requires either full read access on the record so a `_can_return_content` override granting content-level access.

The root cause was introduced in [1]: that commit removed the blanket `base.group_public`/`base.group_portal`/`base.group_user` read grants on `payment.method`, replacing them with a `base.group_system`-only ACL plus a provider-scoped rule, as part of making payment methods provider-specific. It didn't account for the `website_payment` snippet controller, which relies on public read access to list the available payment methods and their logos.

Fix by:
- Using `sudo()` when searching `payment.method` in `get_supported_payment_methods`
- Overriding `_can_return_content` on `payment.method` to allow public access to the `image` field only.

[1]: bcfeed4b24f5155c111c3866e779bb2f119b9da8

The avatar card tour asserts the systray activity counter, which only counts activities whose state is today or overdue. The test scheduled its activities without an explicit deadline, so activity_schedule fell back to context_today on the class environment, whose superuser has tz Europe/Brussels with demo data. When the test runs between 22:00 and 00:00 UTC, that deadline is tomorrow from a UTC point of view. The state of an activity is however computed in the timezone of its assigned user, and hr_user is created without one, falling back to the server date (UTC). Its activities were therefore planned instead of today, the counter stayed empty and the tour timed out. The admin iteration kept passing because demo data gives admin the same Brussels timezone as the environment that computed the deadline, which is why only half the runs failed (both occurrences at 23:56 and 23:31 UTC).

Schedule the activities with a deadline one week in the past instead: an old deadline is overdue in every timezone, whatever timezone the scheduling environment or the assigned user has, making the counter deterministic at any time of the day.

https://runbot.odoo.com/odoo/error/941407

Forward-Port-Of: odoo/odoo#274679

The avatar card tour asserts the systray activity counter, which only counts activities whose state is today or overdue. The test scheduled its activities without an explicit deadline, so activity_schedule fell back to context_today on the class environment, whose superuser has tz Europe/Brussels with demo data. When the test runs between 22:00 and 00:00 UTC, that deadline is tomorrow from a UTC point of view. The state of an activity is however computed in the timezone of its assigned user, and hr_user is created without one, falling back to the server date (UTC). Its activities were therefore planned instead of today, the counter stayed empty and the tour timed out. The admin iteration kept passing because demo data gives admin the same Brussels timezone as the environment that computed the deadline, which is why only half the runs failed (both occurrences at 23:56 and 23:31 UTC).

Schedule the activities with a deadline one week in the past instead: an old deadline is overdue in every timezone, whatever timezone the scheduling environment or the assigned user has, making the counter deterministic at any time of the day.

https://runbot.odoo.com/odoo/error/941407

Forward-Port-Of: odoo/odoo#274679

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#274332
Forward-Port-Of: odoo/odoo#265781

**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261

Issue before this commit:
=========================
When splitting a done picking that contains at least one stock move whose
done quantity is less than the demanded quantity (product_uom_qty),
an expected singleton traceback occurs.

Steps to Reproduce:
=========================
- Install the stock module with demo data.
- Create a delivery picking for any product with a demand of 5.
- Set the done quantity to 2.
- Validate the picking without creating a backorder.
- Try to split the validated/done picking.
- An expected singleton traceback is raised.

Cause of the issue:
=========================
Previously, attempting to split a done picking simply returned because 
there was nothing left to split.

After this [PR](https://github.com/odoo/odoo/pull/224952), the split action calls **message_post()** to post a note on the original picking 
of the generated backorder. However, no backorder is created when splitting a done picking
since there is no remaining quantity to split. As a result, message_post() is called on 
an empty recordset, leading to an expected singleton traceback.

With This Commit:
=========================
Splitting a done picking has no functional purpose, as there is nothing left to split.
In this case, simply return without performing any action. This preserves the 
previous behaviour and prevents the traceback.

Forward-Port-Of: odoo/odoo#274382

The avatar card tour asserts the systray activity counter, which only counts activities whose state is today or overdue. The test scheduled its activities without an explicit deadline, so activity_schedule fell back to context_today on the class environment, whose superuser has tz Europe/Brussels with demo data. When the test runs between 22:00 and 00:00 UTC, that deadline is tomorrow from a UTC point of view. The state of an activity is however computed in the timezone of its assigned user, and hr_user is created without one, falling back to the server date (UTC). Its activities were therefore planned instead of today, the counter stayed empty and the tour timed out. The admin iteration kept passing because demo data gives admin the same Brussels timezone as the environment that computed the deadline, which is why only half the runs failed (both occurrences at 23:56 and 23:31 UTC).

Schedule the activities with a deadline one week in the past instead: an old deadline is overdue in every timezone, whatever timezone the scheduling environment or the assigned user has, making the counter deterministic at any time of the day.

https://runbot.odoo.com/odoo/error/941407

Forward-Port-Of: odoo/odoo#274679

Steps to reproduce:
1. Create a log note or send a message on any record and open the full composer.
2. Set a date in the future to schedule the message for later and click schedule.
3. Click on the "Edit" button of the newly scheduled message.
4. Try dragging and dropping an image into the body, or add a file as an attachment using the button.

Issue:
- Dragging and dropping an image into the form does nothing.
- Trying to add a file as an attachment using the button triggers a traceback: `TypeError: Cannot read properties of undefined (reading 'resId')`

Why this happens:
- The failure when adding explicit file attachments occurs because the `model` and `res_id` fields were omitted from the `mail.scheduled.message` form view layout in the commit 3b985d2. Without these field  declarations, the `mail_composer_attachment_selector` widget cannot determine the record metadata parameters, causing the upload to crash.
- The failure of the drag-and-drop mechanism occurs because the scheduled message edit view uses the default `FormController` class instead of `MailComposerFormController` which is used in the `mail_compose_message` view. Consequently, the underlying `useCustomDropzone` is never instantiated on the view, leaving drop events unhandled.

Fix:
1. Specify `js_class="mail_composer_form"` to the scheduled message form view definition tag to handle drag and drop, as well as adding the missing fields
2. Assign the `resIds` variable based on the message type since it is defined as `res_id` instead of `res_ids` in `mail.scheduled.message`.

opw-6273260

Forward-Port-Of: odoo/odoo#268515

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#274332
Forward-Port-Of: odoo/odoo#265781

The avatar card tour asserts the systray activity counter, which only counts activities whose state is today or overdue. The test scheduled its activities without an explicit deadline, so activity_schedule fell back to context_today on the class environment, whose superuser has tz Europe/Brussels with demo data. When the test runs between 22:00 and 00:00 UTC, that deadline is tomorrow from a UTC point of view. The state of an activity is however computed in the timezone of its assigned user, and hr_user is created without one, falling back to the server date (UTC). Its activities were therefore planned instead of today, the counter stayed empty and the tour timed out. The admin iteration kept passing because demo data gives admin the same Brussels timezone as the environment that computed the deadline, which is why only half the runs failed (both occurrences at 23:56 and 23:31 UTC).

Schedule the activities with a deadline one week in the past instead: an old deadline is overdue in every timezone, whatever timezone the scheduling environment or the assigned user has, making the counter deterministic at any time of the day.

https://runbot.odoo.com/odoo/error/941407

Forward-Port-Of: odoo/odoo#274679

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#274332
Forward-Port-Of: odoo/odoo#265781

# How to reproduce
- Install the Website module
- Install another module that has atleast one model with one html field,
sanitize=Flase or sanitize_form=False and groups
- Remove the field's group from the current user
- Enable dev mode
- Go to Settings > Technical > Database Structure > Models
- Pick any model (e.g. sale.order.line)
- Add a field to that model & Save
- Delete the added field & Save

> Note : Significantly harder to reproduce since :
https://github.com/odoo/odoo/commit/9a336bbb94b0a4266d84f7554c024c3abd2d1e7c
I am not sure a field as mentionned in the steps exists

# The problem
An access error is raised for the module wich access rights were
removed, even if the module is not linked in any way with the picked
model

# Cause of the issue
Deleting the field will endup calling the `unlink()` method of
`BaseModel` on the `ir.model.fields` record. This function triggers all
`@api.delete` methods defined on the model :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/odoo/models.py#L4548-L4552

This will call the this method :
https://github.com/odoo/odoo/blob/5538132d9d14c4cc5031fc50ac0388ad2ab0fc92/addons/website/models/website_form.py#L153-L154

That was introduced by :
https://github.com/odoo/odoo/commit/c0a827519844ec43537e4487f6abe358bb82ba9a

Which prevents a field from being deleted if it is actively used in any
website form. But this method does a search on every model return by
`_get_html_fields` which may contains models that are not accessible by
the user, so we get an access error.

# Proposed solution
Since `_check_if_used_in_website_form` should perform the same
independently from the user, we can do the search in sudo

opw-6231951

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

Forward-Port-Of: odoo/odoo#272916
Forward-Port-Of: odoo/odoo#265781

**Problem:**
When scheduling a message using an email template with custom attachments, those attachments will not have their `res_model` and `res_id` updated to relate to the scheduled message record. This can lead to access errors.

**Cause:**
When composing a message using an email template with attachments, those attachments are created with their `res_model` and `res_id` values corresponding to the mail composer record. However, when scheduling a message, only attachments with no `res_id` value (or a value of 0) are updated to correspond to the scheduled message record. https://github.com/odoo/odoo/blob/77b180e8251fb8019e0034e1c2f485fd2c34ea4e/addons/mail/wizard/mail_compose_message.py#L1198-L1201
https://github.com/odoo/odoo/blob/30ca89b9e0d3c43d019167ec2de816c263f4bb92/addons/mail/models/mail_scheduled_message.py#L86

**Purpose:**
Modify the `mail.scheduled.message` override of `create` to not require an attachment have no `res_id` value to be properly updated.

**Steps to Reproduce in Runbot:**
1. Add an attachment to an email template.
2. Open a mail composer using that email template, then schedule the message for later.
3. Attempt to view the scheduled message with a different user.

More specific example flow:
1. Add an attachment to the Sales: Send Quotation email template.
2. Create a Quotation and send it with the Send by Email button, selecting Send Later instead of Send.
3. Attempt to view the Quotation with a different user.

opw-6293587

Forward-Port-Of: odoo/odoo#272261

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

`useEffect` (OWL3's reactive effect) was tried first but caused regressions: it runs eagerly during `setup()` before mount, so `updateActiveNode`'s call to `viewRenderer.el.querySelectorAll` hit a null element. `onMounted` + `onPatched` restore the exact post-DOM-patch timing of the former `useLayoutEffect`, making the behaviour correct without any reactive-subscription machinery. `activeNodeXpath` is read inside `onPatched` but that hook is not a reactive context, so reads are naturally untracked — matching the original `untrack` wrapper. The `isInEdition` reset is written through `toRaw(viewEditorModel)` so the setter side-effect (`ui.unblock()`) still fires while no re-render is scheduled, avoiding an infinite patch loop.

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/restore active notebook tab and element
- @web_studio/view_editors/interactive_editor/blockUI not removed just after rename
- @web_studio/view_editors/interactive_editor_sidebar/update sidebar after edition
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2602194/build/115250513

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates, in the template, whether the real messages are rendered. That mirroring effect both read `mountedAndLoaded` as one of its dependencies and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write `[isLoaded=true, mountedAndLoaded=false]` pair; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window it drives `mountedAndLoaded` back to false while `isLoaded` stays true, and the settling patch then computes the very `[true, false]` pair already recorded. The effect never re-runs, so `mountedAndLoaded` is stranded at false and no message is rendered.

Depend on a monotonic `resetCount` instead. Reading it in the effect dependency array subscribes the render to it (OWL subscribes a `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: while loading, `applyScroll` resets on every patch, so an unconditional bump would spin the render loop; the guard re-arms only in the case that heals. `reset()` still clears `mountedAndLoaded` (the false dip is needed for the reload scroll handshake), so behaviour is otherwise unchanged.

The race is not deterministically reproducible with this version's test tooling, which cannot advance the render loop a single frame, so no test is added here; the fix is covered by tests on later versions.

https://runbot.odoo.com/odoo/error/940032

Forward-Port-Of: odoo/odoo#274059

When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `Procurement Exception` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user.

Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.

System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs. Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity.

This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.

Steps to Reproduce on Runbot/Fresh Database on version 17.0:
1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
2. Restrict the main Admin (Runbot) user strictly to Company A.
3. Create a Shared Product (Company field left blank).
4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
8. Check the chatter for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.

[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)


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

Forward-Port-Of: odoo/odoo#269395

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="310" height="240" alt="image" src="https://github.com/user-attachments/assets/8768f2e8-9aaa-436b-af9f-40055a6032e9" />


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