**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#248155
Forward-Port-Of: odoo/odoo#241970

[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

Forward-Port-Of: odoo/odoo#247959

**Steps to reproduce:**
- Install Website/Event/Sales apps
- Create a new event and set a ticket price
- Create a fiscal position (with specific tax) for a country with `auto_apply` enabled
- Publish the event
- Register to the event as a anonymous user
- The process bypasses the address form and goes directly to payment
- The resulting sale order will have no fiscal position
- Prices won't be impacted by taxes related to the user billing address

**Issue:**
Address form is skipped before payment for event registration of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit).

**Fix:**
Set `_needs_customer_address` to `True` by default to avoid such issues in
dependant modules. Might need to remove this feature in master as the workarounds are
not that clean (geo_ip, check on fiscal position enabled, overwrite everywhere, others ?).

Similar fix is done for appointments with payment enabled.

related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d
original-task: https://www.odoo.com/odoo/project/49/tasks/4307281

opw-5143124

Forward-Port-Of: odoo/odoo#247054

**Steps to reproduce:**
- Install Accounting
- Install a localization using PEPPOL (e.g. l10n_be)
- Switch to a Belgian company
- In Accounting settings, activate PEPPOL and Audit Trail

- Create an invoice:
  * Customer: [a Belgian customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

Forward-Port-Of: odoo/odoo#248220
Forward-Port-Of: odoo/odoo#247949

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028