This is a backport from 19.4 commit: https://github.com/odoo-dev/odoo/commit/b3c592e27b37b4ac4357d1c4eb33d3afd51c16d4

**Issue**
While confirming a PO for a subcontracted product, the receipt's move takes the company's generic subcontracting location as its source, instead of the location set on the subcontractor partner.

**Steps to reproduce**
- On a subcontractor partner, set a "Subcontractor Location" different from the company's default Subcontracting location.
- Create a subcontracting BOM for a product with that partner as subcontractor.
- Create and confirm a PO for that product with the partner as vendor.
- Confirm the receipt and check the move history -> The incoming move's source location is the generic company "Subcontracting" location instead of the location set on the partner.

**Cause**
While confirming the PO, it creates the associated receipt (picking): https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/purchase/models/purchase_order.py#L719 https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/purchase_stock/models/purchase_order.py#L206

which creates and confirms the associated moves:
https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/purchase_stock/models/purchase_order.py#L384-L385

which retrieves the subcontracting location from either:
- the picking's partner, or
- the company, if it can't get it from the picking: https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/mrp_subcontracting/models/stock_move.py#L154-L156

At that point the move takes it from the company, since the move has no picking yet. It only gets linked to a picking right after: https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/mrp_subcontracting/models/stock_move.py#L158 https://github.com/odoo/odoo/blob/d38e85c54ab25b23e4c3930a48b704a6d34b4ecf/addons/stock/models/stock_move.py#L1625-L1642

opw-6517624

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

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

#### Issue:
When creating a reordering rule for a shared manufactured product in a multi-company database,
saving the rule may raise an `AccessError` on `mrp.bom`.

The orderpoint is still created, but the user sees a record-rule error if the product also
has BoMs in companies that are not currently active.

#### Example:
A product is shared across multiple companies, and each company has its own BoM for that product.
In the reproduced case, the active company has the correct variant BoM.
However, the orderpoint computation first checks the broader product-template BoM relation,
which may include BoMs from the other companies. As a result, Odoo can try to access
a BoM from another company while the user is only working in the active company,
causing an access error.

#### Steps to reproduce:
Use a multi-company database with MRP enabled.
Create or use a shared product available to multiple companies. Create BoMs for that product in more than one company. Set the active company to the company where the reordering rule should be created.
Create a reordering rule for the product.
Save the reordering rule.
Note the AccessError related to mrp.bom.

#### Root Cause:
The MRP orderpoint computations read `product_id.bom_ids` directly. This is the product-template BoM relation and can include BoMs from other companies for a shared product. Reading fields on those BoMs, such as `product_uom_id`, can hit the standard `mrp.bom` multi-company record rule.

#### Fix:
Prefer `product_id.variant_bom_ids` before falling back to `product_id.bom_ids` in the affected orderpoint computations. This avoids reading template-level BoMs from other companies when the product has a variant-specific BoM for the current reordering-rule use case.

opw-6253743

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

Forward-Port-Of: odoo/odoo#276627
Forward-Port-Of: odoo/odoo#267411

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

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

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:**

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 generating a payment complement, tax base and importe coming from the related invoice are prorated by the percentage actually paid, each rounded independently to the currency precision. The post-fix step that restores the SAT invariant uses a Tasa-only formula (`base = total / (1 + rate)`), so Cuota (fixed amount per unit) taxes keep mismatched values, ending up with
`ImporteDR != round(BaseDR * TasaOCuotaDR)`. This leads to CFDIs rejected by the PAC/SAT.

Steps to reproduce:
  - Create a customer invoice with a Cuota IEPS tax (e.g. 26.2569).
  - Register a partial payment whose amount is not an exact divisor of the invoice total (e.g. one third).
  - Send the payment CFDI: the resulting Cuota TrasladoDR has an ImporteDR that does not match BaseDR * TasaOCuotaDR, leading to a rejected CFDI.

This commit recomputes `importe` from the prorated `base` for Cuota taxes (bypassing the Tasa post-fix)

opw-6087564

Forward-Port-Of: odoo/enterprise#131436
Forward-Port-Of: odoo/enterprise#113395

**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

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