**Steps to reproduce:**
- Open Discuss app
- Open any conversation
- Setup the browser with throttled connection (e.g. Slow 4G)
- Select multiple files to attach but don't send the message
- While some are loading, double click the delete button of one of the loaded attachment preview
- Traceback will appear: `404 Not Found`

**Issue:**
On click the delete button triggers a deletion request on `/mail/attachment/delete`.

Repeatedly clicking the delete button before the first request was completed (and the `AttachmentList` get updated) but after the attachment was deleted, will cause a `404 Not Found` due to the `raise NotFound()` which was added by [1] in `mail_attachment_delete`.

```py
attachment = request.env["ir.attachment"].browse(int(attachment_id)).exists()
if not attachment or not attachment._has_attachments_ownership([access_token]):
    request.env.user._bus_send("ir.attachment/delete", {"id": attachment_id})
    raise NotFound()
```

**Fix:**
Prevent concurrent deletion requests for the same attachment by keeping track of attachments currently being deleted.

[1] https://github.com/odoo/odoo/commit/50f45dd436b97027cb1461410efeee7057dad4e8#

opw-6499125

Forward-Port-Of: odoo/odoo#285060

Issue:
---
When a quotation header/footer PDF has a hierarchical AcroForm field,
the value set for that field is silently dropped from the generated PDF
Quote when running on pypdf 5.4.0.

Steps to reproduce:
1- Using a python 3.13 env, install requirements.txt (or otherwise
   run with pypdf==5.4.0 instead of PyPDF2).
2- Upload a header/footer PDF whose form field is a hierarchical field (`/T`/`/FT`/`/V` on the parent, not on the widget itself). The attachment from the ticket can be used as a sample to reproduce the bug.
3- Create a SO and select that document in the Quote Builder tab.
4- Print -> PDF Quote.
5- The value bound to that field does not appear in the printed PDF.

Cause:
---
After https://github.com/odoo/odoo/commit/4b02fbd717f62dd5345dad3ffb8d428c1c180007 `_add_pages_to_writer`
renames the parent `/Field` object's `/T` when the widget itself has
none. PyPDF2's `addPage` inserted the reader's page as is, keeping the
widget's `/Parent`. pypdf 5.4.0 deep clones the page instead and
ignores `/Parent` at every depth, so the widget loses the link to that
field. It ends up with neither `/T` nor `/FT`, hence nothing matches the
value mapping.

Fix:
---
Merge the field into its widget annotations instead: copy the prefixed
`/T` and the inheritable keys onto each of them, then drop `/Parent`.
The field's own `/T` is left untouched, so a field owning several
widgets is filled on all of them.

opw-6508728

Forward-Port-Of: odoo/odoo#287676
Forward-Port-Of: odoo/odoo#286186

Currently, when the user re-reserves a component and produces an MO for a lot-tracked product, putaway rules stop working.

## Steps to produce:
- Install the Manufacturing application.
- Go to Settings and enable Lots & Serial Numbers and Storage Locations.
- Create a product named 'Laptop' and set it to be tracked by Lots.
- Create a product named 'Graphics card' with some quantity on hand.
- Create a Bill of Materials (BoM) for the Laptop with Graphics card as a component.
- Create a location named 'Laptop Shelf' with 'WH/Stock' as its parent location.
- Create a putaway rule:
  - When a product arrives in: WH/Stock
  - Product: Laptop
  - Store to: WH/Stock/Laptop Shelf
- Create and confirm a Manufacturing Order (MO) for the Laptop.
- Unreserve the components, open Details, and re-add the Graphics card.
- Click Produce All and check the on-hand quantity list view of the Laptop.

## Issue:
The Laptop is stored in WH/Stock instead of WH/Stock/Laptop Shelf.

## Root cause:
When the user presses the unreserve button the finished move is passed to `_do_unreserve`
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L2407

which unlinks all the move lines on finished product moves if they are not picked:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L1043

Now when the user presses the Produce All button, `button_mark_done` is called, which calls `_post_inventory` at:
https://github.com/odoo/odoo/blob/a51ca77c825d2dba326dd540e2b4c04ef6c2385d/addons/mrp/models/mrp_production.py#L2236

`_post_inventory` assigns `lot_ids` to the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1928-L1930

This calls `_set_lot_ids` which creates a move line with quantity 1 at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L679-L683

After that, `_post_inventory` sets the quantity for the finished product moves at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/mrp/models/mrp_production.py#L1935

Which calls `_set_quantity` and the  delta quantity is now zero at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L477-L483

Because `_set_lot_ids` has already created a move line that satisfies the move quantity, `_process_increase` is not called.

Since `_process_increase` is not called, `_set_quantity_done` is never called at: https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L463-L465

Since `_set_quantity_done` is not called, `_apply_putaway_strategy` is never called within that function at:
https://github.com/odoo/odoo/blob/157874aad3aebef5bc9268de6e17530641107e31/addons/stock/models/stock_move.py#L2565

As a result, the laptop ends up in stock instead of on the shelf.

This issue did not occur in lower versions because the feature to produce multiple lots was introduced in version 19.0 by the following commit: https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e

Before this commit, only `_set_quantity` was called. Since no move line was created because lot_ids were not set in `_post_inventory`, `_process_increase` was called, which then called `_apply_putaway_strategy`, so the putaway rules were applied correctly.

## Solution:
Apply putaway rules in the post-inventory function after the user manufactures a product, ensuring the items are placed in the correct locations and preventing products from being misplaced even when putaway rules are defined.

opw-6517324

Forward-Port-Of: odoo/odoo#287390

Steps to reproduce:
- Create a gift card program (several programs sharing the same gift card product show the same issue)
- In the PoS, sell a physical gift card: click the gift card product and set a code through "Sell physical gift card?"
- Click the gift card product again to sell a second physical card of the same value
- Validate the order

Issue:
The second unit is merged into the already coded orderline (one line, qty 2, one code), so the "Sell physical gift card?" link is no longer displayed and the second code cannot be entered. Validating the order then fails with "The operation cannot be completed: A coupon/loyalty card must have a unique code." and the order stays unsynced: the qty 2 line is split into two point entries both carrying the same gift_code, so two loyalty.card records are created with the same code.

Cause:
_setupGiftCardOptions() (and setupEWalletOptions()) pass merge=false so that a gift card line is never merged, and until 17.0 add_product() honored it ("options.merge !== false"). The 18.0 store refactoring dropped it: addLineToOrder() decides merging from a local variable that is only set to false when a price_unit is given in vals, and never reads opts.merge. The option became dead code, in point_of_sale's addLineToOrder as well as for the pos_discount caller.

Fix:
Honor opts.merge === false in addLineToOrder(). Callers that do not pass the option are unaffected, so the default merging behaviour is byte-for-byte the same; only the callers explicitly forbidding a merge (gift card, ewallet and discount lines) get their pre-18.0 behaviour back.

opw-6466324

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

Forward-Port-Of: odoo/odoo#287486
Forward-Port-Of: odoo/odoo#286237

#### Issue

When manually adding component lines in the subcontracting Record Production flow, extra stock move lines can remain in the database without a linked stock move.

Those lines have no move_id, so their related state is empty. They can later be selected by stock reservation code and cause validation errors when processing the transfer.

#### Steps to reproduce

1. Create a subcontracted product.
2. Confirm a subcontracting receipt/purchase flow for that product.
3. Open the subcontracting Record Production popup.
4. Remove an existing component line.
5. Add a new component line for another storable product available at the subcontractor location.
6. Save/record the production.
7. Check stock.move.line records ,  Inventory > History > Group By Status.

An extra stock move line is left with no move_id.

#### Root cause

The inverse of `mrp.production.move_line_raw_ids` already collects and deletes move lines detached from existing raw moves.

However, when the user adds a new component product, the inverse creates a new additional raw move. Creating that raw move can also create reserved move lines. The inverse then replaces `move.move_line_ids` with the user-entered lines, but it did not collect the newly created reserved lines before replacing them.

Those reserved lines were detached from the move and left in the database as orphan stock move lines.

#### Fix

Apply the same cleanup logic to newly created additional raw moves: collect their auto-created move lines before replacing `move_line_ids`, then unlink those detached lines at the end of the inverse.

opw-6304649

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

Forward-Port-Of: odoo/odoo#281864
Forward-Port-Of: odoo/odoo#276235

### Steps to Reproduce:
1) Install `website_helpdesk_slides_forum` module
2) On a Helpdesk team, link 2 (or more) forums under `Commnity Forums`.
3) Click on website smart button and then click `Ask the community` button.

### Error:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
KeyError: '_forums'
Template: website_helpdesk_slides_forum.helpdesk_forums
```

### Root Cause:
https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L18-L22

On clicking the "Ask the Community" button calls the `helpdesk_forums`
controller. A single forum redirects straight to it. Several forums get rendered
through `get_template_xml_id()`, with only `forums` in context.

`get_template_xml_id()` is overridden in `WebsiteSlidesForumHelpdesk`,
which points to :

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_slides_forum/views/helpdesk_templates.xml#L3-L5

a primary copy of the inner partial `forum_all_all_entries`. That
partial needs `_forums` (and, once extended by website_slides_forum,
courses_discussions too), both only ever set by the page template's
own t-call:

[Reference](https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/website_forum/views/forum_forum_templates_forum_all.xml#L18-L19)

Since `helpdesk_forums` is rendered directly instead of going through
`website_forum.forum_all`, `_forums` is never set, hence
`KeyError` occurs.

The base `website_helpdesk_forum` module has the same root cause one
level up, surfacing as a different error:

https://github.com/odoo/enterprise/blob/1bdd673c5fd19e335dc0948d2beed7a282e5e172/website_helpdesk_forum/controllers/website_forum.py#L24-L25

`website_helpdesk_forum.forum_all` does not exist anywhere in the
codebase. A team with multiple forums, without
`website_helpdesk_slides_forum` installed, hits
```
ValueError: View 'website_helpdesk_forum.forum_all' in website 1 not found
```
Instead of a listing page.

### Fix:
- Both `get_template_xml_id()` implementations now return the real,
  working `website_forum.forum_all` page template, which already sets
  `_forums/courses_discussions` through its own `t-call` and wraps the result in
  website.layout.

- `helpdesk_forums()`'s render values are now built through an overridable
  `_get_helpdesk_forums_render_values()` hook instead of a hardcoded dict,
  so subclasses can extend the context.

- `website_helpdesk_slides_forum` uses that hook to set
  `hide_forum_slides_link=True`, and adds one small non-primary view inheriting
  `website_slides_forum.forum_all_all_entries` that conditions the `/slides` promo
  link (not the "Course" badge, which doesn't navigate anywhere) on `not`
  `hide_forum_slides_link`. This targets the link element itself rather than a
  `t-call` site in `forum_all`, so it correctly applies whether `website_slides_forum`
  groups a given forum as "regular" or "course-linked".

**opw-6332175**

Forward-Port-Of: odoo/enterprise#131435
Forward-Port-Of: odoo/enterprise#124104

### Steps to reproduce:
- Install `sale_subscription_timesheet` module
- Create a subscription (Order A) with delivered-timesheet products and log timesheets within its current period (e.g., January)
- Create a standard order (Order B) with delivered-timesheet products and log timesheets outside of Order A's period (e.g., March)
- Select both orders and invoice them simultaneously in a single batch (uncheck 'Consolidated Billing')
> Result: Order B's invoice is created but silently fails to link its March timesheets, because they fall outside Order A's January window.

### Cause of Issue:
In `_link_timesheets_to_invoice`, the `start_date` and `end_date` parameters are overwritten inside the invoice line loop when `_get_range_dates` is called. Because these variables are never reset per iteration, the first order that yields a date range locks in that window for every subsequent invoice line in the batch. Timesheets outside this leaked window are silently ignored.

Additionally, the `_get_range_dates` hook is invoked before verifying if the invoice line actually contains timesheet products, causing it to execute on empty recordsets (e.g. invoice line notes)

### Fix:
Prevent the date range leak by preserving the original parameter state of the dates and safely ensure the extension hook is never invoked with an empty recordset.

opw-6507110

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

Forward-Port-Of: odoo/odoo#287358
Forward-Port-Of: odoo/odoo#284781

Current behavior:
--
Registering a super payment from a pay run opened out of the Pay Runs kanban fails with "Wrong value for account.payment.state. The same super contribution registers without error when opened from Payroll > Reporting > Australia > Super Contributions.

Expected behavior:
--
Register Super Payment should work regardless of how the super contribution record was reached.

Steps to reproduce:
--
- Take an Australian pay run through to Paid
- Open Payroll > Payslips > Pay Runs, kanban grouped by Status (default)
- Open the pay run from the Paid column, then Super Submissions
- Lock the super contribution and click Register Super Payment

Cause of the issue:
--
The Pay Runs kanban is grouped by state, so the web client adds default_state to the context of records opened from a column. That context follows the smart button into action_register_super_payment, where account.payment is created without an explicit state. The ORM applies default_state from the context which is a
hr.payslip.run value that account.payment.state does not accept. The same leak reaches account.move through action_post, which creates the payment journal entry.

Fix:
--
apply with_context(clean_context(self.env.context)) to the recordset to remove the default_state key

opw-6478084

Forward-Port-Of: odoo/enterprise#128724

**Description of the issue/feature this PR addresses:**

When a dynamic product carousel is set to single-image scrolling mode in an RTL language (e.g., Arabic), sliding between items behaves inconsistently, resulting in empty spots or temporarily distorted images.

This occurs because the DOM manipulation creating the infinite scroll was coded for LTR physical movements. In LTR, the first DOM element is visually on the left. In RTL, the visual layout is mirrored, with the first DOM element visually on the right. When we then trigger a "left" slide in RTL, the LTR-based JavaScript doesn't appropriately move the last element to the first index prior to the animation, resulting in an empty gap, among other issues.

This commit resolves the issue by checking the document's text direction. By swapping the target direction ("left" or "right") in onSlideSingleScroll and onSlidSingleScroll when RTL is active, the underlying array operations now correctly align with the animation.

**Steps to reproduce:**

- Website > Edit > add Product Carousel > Customize > change Scrolling Mode to Single
- Website > Edit > Theme > Website > Language > change to Arabic
- Click the arrows in the product carousel > observe inconsistent scrolling with visual glitches


**Current behavior before PR:**

- Visual glitches when sliding carousels in single-image scrolling mode for RTL languages

**Desired behavior after PR is merged:**

- No visual glitches when sliding carousels in single-image scrolling mode for RTL languages

opw-6490277

Forward-Port-Of: odoo/odoo#286042

When we save a sale order just after reordering its sale order lines, there's a chance that an error is thrown

Steps to reproduce:
1. Install Sales
2. Go to Sales and open any quotation that has multiple sale order lines
3. Reorder a sale order line and immediately save (there's more chance to reproduce if you have a lot of sol and if you use the shortcut `ALT + S`)
4. An error is thrown

Issue:
It is possible that the save takes place during the execution of super.sortDrop. This reassigns the id of all the records in this.props.list.records
Therefore, calling `_handleQuantityAdjustment` with the recordMap computed before the save uses an id that has disappeard from this.props.list.records so we cannot find it at
https://github.com/odoo/odoo/blob/4973903252865a6a7a2da235bc3a01675dbbff4d/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L263
which eventually throws an error

Solution:
Suspend any save mechanism when sortDrop starts and resume it when sortDrop has finished

opw-6483206

Forward-Port-Of: odoo/odoo#286787

An automation rule triggered when a field reaches a specific value can run its actions twice when a record is created without that field provided explicitly.

For example, a rule that sends one email and schedules two activities can send two emails and schedule four activities for one record.

### Reproduction Steps

Create an automation on `crm.lead` that triggers when the stage is set to "New", with one email action and one activity action. Create an opportunity through the website contact form, which leaves the stage unset.

The lead is assigned to the "New" stage, but both actions run twice.

### Cause

The lead stage is computed and read during creation. That computation can trigger the automation before the creation hook processes the same record, causing both paths to run the actions.

The processing code tracks records already handled during nested computations. The feedback flag used for this tracking is attached to the records, but the code checked the automation context instead. When the computation was triggered during creation, the flag was therefore missed.

### Fix

Read the feedback flag from the records so nested computations update the shared tracking state. The creation hook then skips records already processed by the computation.

opw-6331134

Forward-Port-Of: odoo/odoo#288222

Description of the issue/feature this PR addresses:

A file upload through `FileInput` (and therefore every `many2many_binary` field) still calls `onUpload` after the component has been destroyed. When the form or dialog holding the field goes away while the upload request is in flight, the response crashes the web client with two "Odoo Client Error" popups and the uploaded attachment is orphaned.

Steps to reproduce on a stock database (19.0, and 17.0 carries the same code):

1. Open an Email Template form (Settings > Technical > Email Templates), page *Options*, field *Attachments*. Any `target="new"` wizard with a `many2many_binary` field shows the same thing, e.g. the Recruitment *Refuse* wizard.
2. Pick a file that takes a moment to upload (a few MB, or a slow connection).
3. Before the file tile appears, leave the form through the breadcrumb, or close the wizard with Escape, its close button, or its action button. Nothing in the field shows that an upload is still running, so users do this routinely.

Current behavior before PR:

When the upload response arrives, two errors are raised:

```
UncaughtPromiseError > Component is destroyed
    at webRead <- _loadRecords <- _applyCommands <- addAndRemove
TypeError: Cannot set properties of null (setting 'value')
    at FileInput.onFileInputChange
```

Cause: `FileInput` posts the file through the `http` service, which is not protected against a destroyed component (unlike `orm`), so the response still reaches `onFileInputChange` after the component, the field and the form controller are gone. It then calls `onUpload`, which for `Many2ManyBinaryField` links the attachment through the form controller's protected ORM (hence the rejection), and it clears a file input ref that no longer exists (hence the TypeError).

We hit this in production on three different wizards over a few months. The client error logs users saved all carry the same trace, and the audit log shows the dialog's action completing a fraction of a second before the upload landed.

Desired behavior after PR is merged:

After the upload resolves, `onFileInputChange` stops when the component is destroyed: nobody is left to receive the uploaded files, and this matches how the protected services already treat a destroyed component. No error is raised, and `onUpload` is not called.

A Hoot test in `file_input.test.js` mounts a `FileInput` behind a `t-if`, starts an upload, unmounts the input while the upload is pending, resolves the upload, and asserts that `onUpload` was not called. It fails before the fix with the two errors above and passes after.

`master` already guards the ref write through its signal-style refs, but still calls `onUpload` on the destroyed component, so the first error remains there.

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

Forward-Port-Of: odoo/odoo#286831

**Description of the issue/feature this PR addresses:**

Fixes #287978

In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only
trigger the `FIELD_IS_DIRTY` bus event with `false` when the newly typed value
actually differs from the value already stored on the record. When the typed
text parses to the *same* value as what is already on the record (e.g.
retyping `6,250` after the field already holds `6,25`), the code takes the
`else` branch, which only resets the displayed text and never notifies the
bus that the field is no longer dirty.

`form_status_indicator.js` keeps whatever `fieldIsDirty` state it last
received from that bus event, and shows the Save/Discard buttons whenever
`root.dirty || fieldIsDirty`. Since nothing ever fires `FIELD_IS_DIRTY(false)`
in that `else` branch, `fieldIsDirty` stays stuck at `true`. `Discard`
correctly resets `root.dirty`, but has no way to reset `fieldIsDirty`, so the
Save/Discard buttons keep showing even though the record is clean.

**Current behavior before PR:**

1. Edit a field to a new value, click away (value committed, indicator shows
   Save/Discard as expected).
2. Edit the same field again, this time typing different text that parses to
   the *same* value (e.g. `1.20` when the field already holds `1.2`), click
   away.
3. Click **Discard**.

The record is reverted, but the Save/Discard buttons remain visible. They
stay stuck until the page is reloaded.

**Desired behavior after PR is merged:**

Retyping different text that parses to the same value clears the field's
dirty state like any other case where the field ends up unchanged, so
Discard (or any other action) correctly hides the Save/Discard buttons once
there is nothing left to save.

Forward-Port-Of: odoo/odoo#288030

### Issue:
When a bank account is manually set on a bill for a partner with multiple bank accounts, using the Auto-Complete feature could reset the manual selection even without a currency change

### Cause:
When `invoice_vendor_bill_id` is set, an onchange assigns `currency_id` unconditionally, even when it is the same value
This triggers `_compute_partner_bank_id`, which always recomputes the best matching bank account from scratch without considering the currently set value
If the currency did not change, this recompute is unnecessary and silently overrides the manual selection

### Steps to reproduce:
- Install `account`
- Create a Vendor with 2 bank accounts (keep default values to have equal priority on all accounts)
- Create and post a Bill for this vendor with at least one line
- Create a new Bill for the same vendor
- Set the Recipient Bank to the second account in the list
- In Auto-Complete, select the first Bill
 
Before the fix, the Recipient Bank is reset to the first account

opw-6210414

Forward-Port-Of: odoo/odoo#283479

Steps to reproduce:
--------------------------------------------
1. Install `sale_timesheet` module
2. Create a product with:
    * Type: Service
    * Invoicing Policy: Prepaid/Fixed Price
    * Create on Order: Project & Task
    * Upsell Threshold: Set some value (e,g. 600%)
3. Create and confirm the sale order with that product
4. Create and confirm an invoice for the sale order
5. From Recorder Hours Smart button:
    * Add two timesheets for hours 3 & 4 (Combined h > Threshold Percentage/100)

Observation:
--------------------------------------------
* When adding a single 7h timesheet, an upsell warning activity is correctly created for the salesperson in the chatter.
* When adding multiple incremental timesheets whose combined duration exceeds the threshold, no upsell warning activity is created.

Issue:
--------------------------------------------
* The `_compute_field_value` method filters on `invoice_status != 'upselling'` before recomputing the new invoice status.
* After the first incremental timesheet is added, the sales order already has the upselling status from the previous computation.
* As a result, subsequent computations skip the upsell activity logic, even though `has_displayed_warning_upsell` is still `False` and no warning activity has yet been created.

Solution:
--------------------------------------------
* Removes the `so.invoice_status != 'upselling'` condition from the filter.
* The order-level `invoice_status` was never the right place to control upsell activity creation. An order can have `invoice_status == 'upselling'` for various reasons (delivered > invoiced), but that doesn't mean all lines have already triggered their upsell warnings.

opw-6117754

Forward-Port-Of: odoo/odoo#287642
Forward-Port-Of: odoo/odoo#266275