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

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

Currently, if you refund an order fro the backend it is possible to modify the qty as if to refund more than the original order qty.

Steps to reproduce:
-------------------
* Make an order from the shop (1 product, qty 1)
* Validate the order
* Go backend
* Find the order and select the refund button
* Change qty from -1 to -3
* Save and continue the refund process
> No problem refunding more than the original quantity

Why the fix:
------------
In the frontend we cannot refund more than the original quantity, we assume the same should be in the backend process.

The most simple way to do this is by doing a difference between the quantity from the original order and all the refund lines linked.

From `self.refunded_orderline_id.refund_orderline_ids` we need to exclude the line that represents self as it holds the quantity before the onchange and we care about the quantity we're trying to write not the previous (allegedly correct).

opw-6328635

Forward-Port-Of: odoo/odoo#287209
Forward-Port-Of: odoo/odoo#281405

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

Steps to reproduce:
- Install eCommerce and Click & Collect.
- Publish Pick up in store with a warehouse whose address is in country A (e.g. United States).
- Publish a country-specific delivery method (Fixed Price, non-zero) limited to country B (e.g. Spain).
- On the shop, checkout with a delivery address in country B.
- Select Pick up in store, then select the country-specific method.

Issue:
Selecting the country-specific method keeps Delivery at 0 (Free). The same happens with country-restricted connectors: `/shop/set_delivery_method` never applies the method, so no rate is requested for that switch.

Cause:
Since saas-19.3, a pickup location replaces `partner_shipping_id` with a generated pickup address. `/shop/set_delivery_method` only calls `_set_delivery_method` if the method is in `_get_delivery_methods()`, which matches on the shipping address. The pickup country makes the country-specific method look unavailable, so it is never applied. The order still has the pickup method (0 delivery), and the summary reports the selected method as Free.

Match availability on the customer when shipping is a pickup address, and restore that address before rating the method that is being set. Keep the Based on Rules check so a method with no applicable price rule is not listed after pickup.

opw-6493956

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

Forward-Port-Of: odoo/odoo#285068

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

**Steps to reproduce:**
* Install the **Manufacturing** module with **Work Orders** enabled.
* Create and confirm a Manufacturing Order with at least one Work Order.
* Open the **Shop Floor** view.
* On a work order card, click the **gear** icon to open the menu dialog.
* Click **Open Manufacturing Order** on a slow network connection.
* Before the MO form view finishes loading, quickly click the **gear** icon again and open another dialog (e.g. Log Note).
* The MO form view loads, destroying the shop floor component.
* Close the Log Note dialog.

**Observed behavior:**
* An `UncaughtPromiseError: Component is destroyed` error is thrown because the dialog tries to interact with the shop floor component that has already been destroyed by the navigation to the MO form view.

**Cause:**
* When the user clicks "Open Manufacturing Order", `doAction` is called to navigate to the MO form view, and `props.close()` immediately closes the menu dialog. However, the shop floor component is still visible while the new view is loading.
* During this gap, the gear button remains clickable. If the user opens another dialog (e.g. Log Note), that dialog holds a reference to the shop floor component. When the MO form view finishes mounting, the shop floor is destroyed, and closing the stale dialog triggers operations on the destroyed component.

**Fix:**
* Add an `actionPending` state flag to `MrpDisplayRecord`. When the user selects "Open Manufacturing Order" from the menu dialog, an `onSelect` callback sets `actionPending` to `true`, which disables the gear button and prevents any new dialog from being opened.
* The flag is only set for `openMO` (which navigates away and destroys the component), not for other menu actions like Scrap, Add Component, or Log Note which open wizard dialogs and return to the shop floor.

opw-6107579

Forward-Port-Of: odoo/enterprise#131448
Forward-Port-Of: odoo/enterprise#123490

### Issue before this commit:
When users enabled the "Use Documents" option on a Purchase journal and created a vendor bill with a specific document type (e.g., type 31) and number (e.g., E3100056), creating a new customer invoice with the same document type would incorrectly continue the sequence from the vendor bill's number (e.g., E3100057).

### Steps to reproduce the issue:
1. Download Accounting and l10n_do_edi
2. Go to invoices and vendor bills and delete all of them
3. Go to Journals and tick Use Documents options for Sales and Purchases journals
4. Create a vendor bill setting the document type as for example (31) Electronic Tax Credit Invoice and the document number as for example E3100056
5. Create an invoice and set the same document type
6. See that the sequence will increase by 1 but starting from the last number setted (so it will be E3100057) when you create a new invoice

### Cause of the issue:
https://github.com/odoo/enterprise/blob/d4da04a036486818c12712a200a3482a66921abf/l10n_do_edi/models/account_move.py#L346-L354
The _get_last_sequence_domain override is fetching the last sequence across the company based on the document type, but it did not filter by move_type. Consequently, it was catching vendor bill numbers (in_invoice) to compute the next sequence for customer invoices (out_invoice).

### Reason to introduce the fix:
Restrict the sequence lookup to sales documents will ensures that vendor bill references do not interfere with the official sequential numbering of customer invoices.

opw-6430906

Forward-Port-Of: odoo/enterprise#128178

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