[FIX] website: enable custom javascript on website
Steps to reproduce the problem:
- Go to the "HTML/ CSS Editor".
- Go to the JS tab.
- Uncomment the example and save.

-> Problem: the confirmation dialog does not appear.

The problem is that since [1], `/* @odoo-module */` has been removed
from the file as since [2], js files in `/static/src` and
`/static/tests` are considered as odoo module without the need of the
annotation `odoo-module`. In order to understand the problem, here is a
summary of what happens when a custom js code is saved;
- An attachment is created with the custom js code.
- An asset is created to replace the user custom rules of
`user_custom_javascript.js` by the one of the newly created attachment.

Because the url of the newly created attachment looks like
`/_custom/web.assets_frontend_lazy/website/static/src/js/user_custom_javascript.js`,
the transpiler does not recognize it as an odoo module.

task-5925607

[1]: https://github.com/odoo/odoo/commit/6d2fda172ec9cc7642abe9625ca486c7769e8297
[2]: https://github.com/odoo/odoo/commit/5f2c505836002ac7851c29c28d612f721d467bc4

**Steps to reproduce:**
* Install the *repair* module.
* Create a *storable product* and set some **On Hand** quantity.
* Go to *Repairs* and create a new **Repair Order**.
  Keep the repair order in *draft* state (do not confirm).
* In the **Parts** tab, add the storable product with the operation type set
  to *Add*.
* Open the **Stock Forecasted** report for the added product.
  Note the quantity shown under *Outgoing Draft Transfer*.
* Delete the **Repair Order**.
* Open the **Stock Forecasted** report for the same product again.

**Observed behavior:**
* The quantity still appears in the **Stock Forecasted** report under
  *Outgoing Draft Transfer* even after the repair order is deleted.

**Cause:**
* Deleting a draft repair order triggers `_unlink_except_confirmed`.
* This method prevents related stock moves from changing their state to
cancel when the repair order is deleted.
* The *Outgoing Draft Transfer* value is calculated as the sum of quantities
of stock moves in draft state at draft state.
https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49

https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90

* As a result, deleting a draft repair order leaves related stock moves in
draft state, causing them to appear under *Outgoing Draft Transfer*
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335

**Fix:**
* Ensure that related stock moves are properly cancelled when a draft repair
  order is deleted.

---

opw-5449323

Forward-Port-Of: odoo/odoo#247348
Forward-Port-Of: odoo/odoo#241970

**Step to reproduce:**
1. Install `sale_management`
2. Open any email template (e.g., Sale: Order Confirmation).
3. Add an attachment to it
4. Create a Sale Order, confirm it, and click "Send by Email".
5. In the mail composer, remove the template attachment

**Issue:**
- The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails.

**Cause:**
- The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment.

**Solution:**
1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server.
2. In `onFileRemove`, check the `res_model` of the attachment.
3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink)
   and only remove it from the composer view.

opw-5163679

Forward-Port-Of: odoo/odoo#238692

Occasionally the test_kardex_report test fails:

```
Traceback (most recent call last):
  File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
    self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']

First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'

- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^

+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^
```

The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.

The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.

This commit makes the behavior deterministic by sorting on PO line and SO line ids.

runbot-error-238888

Forward-Port-Of: odoo/enterprise#107047