Before this commit, when sending a message in full composer to explicit recipients and message contains mentions, the resulting recipients of the message were only mentioned users.

Steps to reproduce:
- Open a form view with suggested recipient (e.g. any contacts with demo data)
- Click "Send message" then full composer button ("expand" button)
- Type `@Marc Demo` mention in the full composer text area
- Click on "Send"

=> The new message shows envelope with only "Marc Demo" in the recipients, instead of "Marc Demo" and the suggested recipient.

This happens because when making a mention, the code to enrich the `partner_ids` of `mail.compose.message` was basically setting its content with mentions, without taking into account whether there were some explicit values with other means than with `@mention`.

This commit fixes the issue by adding mentions with the current value of `partner_ids`, so that mentions and explicit recipients are the resulting recipients of message as expected

Task-4366608

Forward-Port-Of: odoo/odoo#189303
Forward-Port-Of: odoo/odoo#189187

Steps to reproduce:

- Navigate to Website
- Open the user dropdown menu and select "My Account".
- On the right-hand side of the page, click on "Edit information".
- Enter edit mode.
- Drag and drop a form inside the existing form.
- Save the changes.
- Re-enter edit mode.
- Click on any field within the newly added form.
- A traceback is triggered.

HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in browsers. To address this, the website_form snippet has been updated to prevent it from being dropped inside another form.

This fix ensures compliance with HTML5 specifications and prevents invalid document structures from being created within the website builder.

Due to this commit [1], buttons were added as inline building blocks. As a result, you could insert blocks either directly before or after the button. Since this wasn't the case before, we never encountered any issues in forms, as nothing could be inserted there.

[1]: https://github.com/odoo/odoo/commit/507b80a12574c

opw-4305352

Forward-Port-Of: odoo/odoo#189079
Forward-Port-Of: odoo/odoo#188028

Versions
--------
- 17.0+

Enterprise: https://github.com/odoo/enterprise/pull/74626

>[!note]
>Enterprise PR only adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144

Forward-Port-Of: odoo/odoo#189151
Forward-Port-Of: odoo/odoo#188440

Problem: When a BoM has a different UoM than the product, it will calculate the number of cycles needed for the work order using the product’s UoM. However, during the cycle time calculation, it uses the BoM’s UoM to calculate the number of cycles used in the previous work orders. It then uses this cycle number calculation to calculate the duration of each cycle. This can cause the expected duration for a work order to be calculated incorrectly.

Purpose: Changing the cycle time’s calculation to use the product’s UoM will make it consistent with the number of cycles calculation on the work order. 

Steps to Reproduce on Runbot:

1. Create a new storable product.
2. Create a BoM for this product, but set the UoM to Dozens.
3. Navigate to the Operations tab and add an operation.
4. Set the Duration Computation to Compute based on tracked time.
5. Create a manufacturing order and confirm it.
6. Navigate to the Work Orders tab, set the Real Duration to 20:00, and mark it as done.
7. Create a new manufacturing order.
8. Navigate to the Work Orders tab and observe the Expected Duration is 240:00.

opw-4239248

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

Forward-Port-Of: odoo/odoo#189445
Forward-Port-Of: odoo/odoo#187649

[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior

As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.

=======================================

[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts

// TO REPRODUCE

1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.

2) Create 3 accounts, with codes 11, 12, 13

3) Create 3 partners: A, B, and C

4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
    - on account 11, with partner A, debit=10
    - on account 11, with partner A, debit=20
    - on account 12, with partner A, debit=25
    - on account 11, without partner, debit=30
    - on account 11, without partner, debit=40
    - on account 12, with partner B, debit=50
    - on account 13, with partner C, debit=60

5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.

    => With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.

// EXPLANATION

The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.

With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.

So, with our example, the query runs with a LIMIT of 3, returning
    - 30 for A on account 11
    - 25 for A on account 12
    - 70 for no partner on account 11

Then, another issue happens:

The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.

The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".

Forward-Port-Of: odoo/enterprise#74998
Forward-Port-Of: odoo/enterprise#74784

Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence.

To reproduce this issue:

1) Install planning
2) Open any existing Open Shift planning slot
3) Enable the `repeat` and update the start and end date 
4) Give the edit value as `All shifts` and make sure the resource be empty 
5) Save the record.

Error:- 
```
IndexError: tuple index out of range
```

Here the `resource` is not required in planning slot. So, when the user tries to update an open shift 
with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line.

https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871

This is because when there is no `recurrence_slots` in the slot, 
we get an empty recordset for the `recurrence_slots`, 
which leads to the above traceback when trying to extract a value from the recurrency_slots.

We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust.

sentry-6096445646

Forward-Port-Of: odoo/enterprise#74866

Versions
--------
- 17.0+

Community: https://github.com/odoo/odoo/pull/188440

>[!important]
>All functional changes are made in `sale`, this PR simply adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144

Forward-Port-Of: odoo/enterprise#74884
Forward-Port-Of: odoo/enterprise#74626