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#189369
Forward-Port-Of: odoo/odoo#189187

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

### Steps to reproduce the issue:

1. With studio, add a signature field to the Expense Form
2. Create a new expense with a signature
3. Receive the following error:

>       File "[...]/odoo/addons/hr_expense/models/hr_expense.py", line 459, in _compute_same_receipt_expense_ids
>         same_receipt_ids.update(expenses_groupby_checksum[attachment.checksum])
>     KeyError: <string of letters and numbers>

### Explanation:

When a Binary field is assigned a value.`ir.attachment` is automatically created and linked to said field through `res_field`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L2514-L2522 In the database, when retrieving attachments, those with `res_field` assigned are discarded from the query. https://github.com/odoo/odoo/blob/bfd7945d634bd4d46c4d62e93061581c6c5b09c1/odoo/addons/base/models/ir_attachment.py#L520-L526 During the creation of `hr.expense`, `attachment_ids` is assigned all attachments created and linked to it, in the cache, through `res_id`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L3290 Since saas-17.4, the compute method `_compute_same_receipt_expense_ids` has been added with a dependency on `attachment_ids`. If, during the creation, a Binary field has been assigned a value and `ir.attachment` created, the latter will still be linked to `attachment_ids` in the cache and found in the `filtered` method, while the `_read_group`, checking the database, will discard it due to `res_field` having a value. https://github.com/odoo/odoo/blob/6b8e07e36c6e6e283d21c2b5abd9a9dabf10fa4a/addons/hr_expense/models/hr_expense.py#L445-L454 Due to that difference between the cache and the database, an issue occurs when trying to retrieve the value from `ir.attachment`.

### Fix reasoning:

`attachment_ids` has a domain attribute, but it is not correctly assigned. The value should be a List instead of a String. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L2991 While this specific domain is not necessary for One2Many fields since it is already covered by the override in `get_domain_list`. https://github.com/odoo/odoo/blob/9b440d5b07d9683d7f051baa98476b2977acba0f/odoo/fields.py#L4497-L4498 We will keep it to make sure the cache is invalidated and `attachment_ids` is retrieved from the database. https://github.com/odoo/odoo/blob/bde4952255987cd21ceaabdf13f0a271b6ab10fa/odoo/models.py#L6889-L6894

opw-4293803

Forward-Port-Of: odoo/odoo#186897

If we replace the original definition then the check between the existing definition and the original one will always fail, thus we are always removing and re-adding the same constraint. https://github.com/odoo/odoo/blob/5ba361ddffa757cf60968f37180c7fd1304b3fd4/odoo/models.py#L3209

Replacing `%` by `%%` works for `LIKE` operator because they are equivalent. Since they are sent as-is to the DB the constraint could actually be plainly wrong.

```sql
test_17=> SELECT coalesce(d.description, pg_get_constraintdef(c.oid))
   FROM pg_constraint c
   JOIN pg_class t
     ON t.oid = c.conrelid
   LEFT JOIN pg_description d
     ON c.oid = d.objoid
  WHERE t.relname = 'ir_model_fields'
    AND conname = 'ir_model_fields_name_manual_field'
+------------------------------------------------+
| coalesce                                       |
|------------------------------------------------|
| CHECK (state != 'manual' OR name LIKE 'x\_%%') |
+------------------------------------------------+
```

Example where the definition sent to the DB is wrong:
```py
class A(models.Model):
    _inherit = "res.users"

    _sql_constraints = [("test_constraint", "CHECK (login !~ '%')", "Cannot have % in login")]
```
```sql
test_17=> \d res_users
...
Check constraints:
    "res_users_test_constraint" CHECK (login::text !~ '%%'::text)
...
```

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

Forward-Port-Of: odoo/odoo#188593

Problem
---------
Additional attachments linked to an Email Template used in the Send & Print are completely ignored. They should not, and it's especially useful for Timesheets.

Steps
---------
1. Install Accouting, Timesheet and Sales
2. In debug, access mail templates
3. Go to the 'Invoice: Sending' record > Setting tab
4. In Dynamic Reports, add 'Timesheet'
5. Go to sale
6. Create an SO with 'Junior Architect' product for 10 units
7. Confirm the SO
8. Click the Timesheet widget on the SO form view
9. Register some hours for today (for example 3 hours)
10. On the SO Form view, click 'Create Invoice'
11. Select the option to invoice timesheeted hours and select from today to today as the date range
12. Create the Invoice and post
13. Send & Print -> The timesheet report appears in the send and print widget, when you click send, the timesheet report is actually not sent.

Solution
---------
1. Add a placeholder in the send&print widget, the placeholders are stored in the `mail_attachments_widget` used for such purposes. The dynamic reports are defined with an new key: `dynamic_report` to differenciate them from the `manual` attachments and the invoice PDF. This new key eases the complexity to retreive and create the attachments fom the placeholders list.
2. Add a method when sending the mails to generate the dynamic reports only if the reports have not been removed in the S&P widget (`skip != False`). Since the attachments placed in the mails are a collection of elements from `mail_attachments_widget` that possess a valid attachment ID. We add the relevant attachment data in the mail_attachments_widget of the invoice.

task-4283972

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

Forward-Port-Of: odoo/odoo#187381

**Steps to reproduce the bug:**

- Create a storable product “P1”:
  - Vendor: Azure Interior
  - Reordering rule:
    - Trigger: Auto
    - Route: Buy

- Go to the user settings and give Marc Demo access only to Sales.
- Log in as Marc.
- Create a sales order:
  - Product: 1 unit of P1.
- Confirm the SO.
- A purchase order is created.
- Create a second SO with another 1 unit of P1.
- Confirm it.

**Problem:**
An error is triggered:
`odoo.exceptions.AccessError: You are not allowed to access 'Purchase Order Line' (purchase.order.line) records.`

When the second SO is confirmed, a quantity request is made, triggering the "buy" rule. A check is made if there is a candidate “purchase order line” with the same specifications to update its quantity instead of creating a new one:
https://github.com/odoo/odoo/blob/a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab/addons/purchase_stock/models/stock_rule.py#L130-L136

The function `_update_purchase_order_line` is called, where access to the taxes associated with the purchase order line is attempted: https://github.com/odoo/odoo/blob/a9cbd2a2ae2e21f1ba14379aecd908c44497b8ab/addons/purchase_stock/models/stock_rule.py#L248

Since it’s a Many2Many field, a query is made to fetch all the records. However, because the user does not have access to the `account.tax` model, an error is triggered.

opw-4193125

Forward-Port-Of: odoo/odoo#181242
Forward-Port-Of: odoo/odoo#181073

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#75046
Forward-Port-Of: odoo/enterprise#74626