### Steps to Reproduce
1. Activate any other language (ex. FR)
2. Create a new Discount code in Discount & Loyalty
3. Change your user language preference to FR, open the newly created loyalty reward, and change the Description on Order to Test Discount for both languages
4. Navigate to the backend Product Variants menu and observe how its name did not translate in English

### Description of the issue/feature this PR addresses:
**Issue:** When you edit a translation for a loyalty.reward description in a multi-language setup, the product name (`discount_line_product_id.name`) fails to receive the complete translation in all languages. It only updates the current language.

**Solution:**
Override the 'update_field_translations' method on the loyalty.reward model. When changes are saved for the 'description' field on the discount code, intercept the payload and mirror directly at the discount product's `name` field.

### Current behavior before PR:
Updating the reward description only updates the current language and all other languages do not change.

### Desired behavior after PR is merged:
For all languages in which changes are made in a discount code's description, the discount line product name will reflect the same changes. 

opw-6314760

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

Forward-Port-Of: odoo/odoo#271680

When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is shown in the discount popup as 8.33% and, when confirmed without editing, applies a 100% discount on the order instead of 8,33%.

Steps to reproduce:
-------------------
* Activate Belgian localization for accounting
* Set the user language to Dutch (Netherlands) or Dutch (Belgium)
* In Point of Sale settings, enable global discounts and set the default discount percentage to 8,33%
* Open a POS session, add a product to the cart, and click Discount
* Confirm the popup without changing the value

> Observation:
The popup displays 8.33% (with a dot). After confirmation, the order receives a full discount instead of 8,33%.

Why the fix:
------------
The discount popup initialized its value with `String(discount_pc)`, which always uses a dot as decimal separator. POS then parses the input with locale-aware rules where `.` is the thousands separator, so "8.33" is read as 833 and capped to 100%. Format the default discount percentage with `formatFloat` so the popup starts with the correct localized value (e.g. "8,33").

opw-6334367

Forward-Port-Of: odoo/odoo#273022

**Issue 1:**

Step to reproduce:
- Type ':wave' to open suggestion list
- Now click on any emoji from the suggestion list

Description of the issue:
- The selected emoji gets inserted, but the `searchNode` `:wave` does not get removed and remains beside the inserted emoji

Cause:
- When the user clicks an emoji from the suggestion list, focus shifts to the suggestion list item. As a result, `selection.extend()` is unable to properly select the searchNode in the editable area. Because the `searchNode` is not selected, `deleteSelection()` fails to remove it before inserting the emoji.

Solution:
- Added the `user-select-none` class to the suggestion list to prevent selection/focus shift on emoji click, ensuring the searchNode is properly selected and replaced by the selected emoji


**Issue 2:**

Steps to reproduce:

- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:

- When using the SwiftKey keyboard, pressing Backspace after an emoji can result in an incorrect cursor position.

Cause:
- When Backspace is pressed, a selection snapshot is cached during the `keydown` event.
- Later, `deleteBackward` converts the emoji back to its corresponding expression (:p) by triggering an undo operation, but the cached selection does not get updated. As a result, the previously cached selection is reused, causing the cursor to be placed incorrectly.

Solution:

- After performing the undo, update the cached selection to match the new cursor position.
- This ensures that the latest selection is used instead of the outdated selection captured during `keydown`.

**Issue 3:**

Steps to reproduce:
- Open a To-do on a mobile device.
- Type `:p` to create an emoji.
- Press Backspace.

Issue:
- Pressing Backspace on an emoji does not revert it to its matching expression (`:p`).

Cause:
- On mobile devices, `event.key` can be undefined in keydown. As a result, `deleteBackward` is triggered through the `beforeinput` event, which correctly reverts the emoji to its matching expression. However, after that, the `input` event is triggered and converts the expression back into the emoji again, making it appear as if the emoji was not reverted.

Solution:
- When the event type is `deleteContentBackward`, skip converting the expression back into an emoji and return early.


task-6201173

Forward-Port-Of: odoo/odoo#263777

### Issue:
In 19.0, the values of lines 415 and 420 in the Swiss tax report are negative, causing line 479 to add them instead of subtracting

Line 479 formula:
`tax_ch_400 + tax_ch_405 + tax_ch_410 - tax_ch_415 - tax_ch_420`
For the subtraction to be correct, 415 and 420 must be positive

### Cause:
In 18.0, each tax grid had two variants (`+415`/`-415`) allowing the user to control the sign manually
The double negative (`-*-`) incidentally produced positive values in the report

In 19.0, the unified tax grid merges them into a single tax grid (`415`) with automatic sign handling
415 and 420 are correction lines that must appear positive in the report so that 479 subtracts them correctly
The formulas were not updated to reflect this change

### Steps to reproduce:
- Install `l10n_ch_reports` and `accountant`
- Switch to `CH Company`
- Create and confirm a Bill (Amount: 100, Tax: 8.1%)
- Create and post a Journal Entry:
  - Account: 1170 Input Tax (VAT), Credit: 2, Tax Grids: 415 and 420
  - Account: 1021 Bank, Debit: 2
- Open the Tax Report for this month
 
Before the fix, lines 415 and 420 are negative and line 479 adds them instead of subtracting

opw-6311126

Forward-Port-Of: odoo/odoo#272385

### Issue:
When a bank journal uses a foreign currency, reconciliation model lines with `Amount Type: From Label` (regex) could raise a constraint error or produce incorrect balances on the journal entry

### Cause:
The `balance` of the generated move line was set to the raw value extracted by the regex, without converting it from the journal currency to the company currency

This violated the sign constraint between `balance` and `amount_currency` when the exchange rate caused a mismatch, raising a `_check_amount_currency_balance_sign` error

The `amount_currency` was already correctly set
Only the `balance` conversion was missing

### Steps to reproduce:
- Install `accountant`
- Enable a foreign currency (e.g. EUR) with two rates: yesterday: ratio < 1 (e.g. 0.5), today: ratio > 1 (e.g. 2.0)
- Create a Bank journal in EUR
- Open Bank Reconciliation for that journal
- Add two transactions (one dated yesterday, one today) (Ref: "test BANK:0001690,00EUR EXP:00033,80", amount: 1656.20)
- Create a reconciliation model (3 dots > Manage Models) (name: From Label):
-- Account: 101401 Bank, Amount: BANK:0*(\d+),(\d+)
-- Account: 600000 Expenses, Amount: EXP:0*(\d+),(\d+)
- Apply the model on both transactions
Before the fix, one raised an error due to the constraint violation
- From the list view, open the Journal Entry for the other transaction
Before the fix, `balance` was not converted to company currency

opw-6292839

Forward-Port-Of: odoo/enterprise#121114

In certain cases the barcode of a product could be a valid standalone 
GS1 sequence. In that case it needs to be be correctly interpreted as 
a product scan.

### Steps to reproduce:

- In the settings enable "Default GS1 Nomenclature"
- Create a storable product P with the barcode 3701762412212
- Create and confirm a  delivery for 2 units of P and set the qty to 2
- Go to the barcode app and open your delivery
- Scan 3701762412212
> The line of P is now selected with a quantity of 1/2
- Scan 3701762412212
#### > A new line is created for 1762411 units

### Cause of the issue:

According to the GS1 nomenclature, the barcode 3701762412212 matches the scan of a quantity of "1762412" units of the lot name "2". As the scan of the of the product match a pattern for the GS1 nomenclature before matching a product, its barcode data is expected to be reset by these lines:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1320-L1324
In order to bypass the GS1 parser and to add 1 unit of the product. This is what happen on the first scan. However, performing the first scan also selects the associated line and, hence on the second scan the lines just above this check do set the product to match the product of the current line:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/stock_barcode/static/src/models/barcode_model.js#L1294-L1320
In particular, we do not bypass the result provided by the GS1 parser and add `1762412` units of the product.

opw-6175621

Forward-Port-Of: odoo/enterprise#122256
Forward-Port-Of: odoo/enterprise#120035

Steps to reproduce
1. Create a service product: Invoicing Policy = Prepaid/Fixed Price, Track Service = Timesheets, Unit of Measure = Days
2. Confirm a Sales Order with 2 days of that product at 800/day
3. Register 1 hour on the generated task
4. Open Timesheets > Reporting, add the "Timesheet Revenues" measure

Issue
`timesheet_revenues` in `timesheets.analysis.report` was computed per analytic line as `(SOL.price_subtotal / SOL.qty_delivered) * (unit_amount * sol_uom.factor / ts_uom.factor)` (https://github.com/odoo/odoo/blob/16f170619d9cc5fd86529a3f17e349da37607f73/addons/sale_timesheet/report/timesheets_analysis_report.py#L42-L44).

`SOL.qty_delivered` is a stored float rounded to the day UoM precision (0.01d). For 1 hour timesheeted, qty_delivered = 1/8 = 0.125d rounds to 0.13d, so the formula yields (1600 / 0.13) × (1/8) = 1538.46 instead of the correct 100. Because `qty_delivered` is recomputed each time a timesheet is added, all existing rows shift their revenue figure with every new entry.

Additionally, using `price_subtotal / qty_delivered` as the per-unit rate ignores any line discount: the rate derived from a discounted subtotal divided by a delivered quantity that differs from the ordered quantity is not the effective price per day.

For prepaid lines, the effective per-unit rate is `price_subtotal / product_uom_qty` — the ordered quantity is stable and the subtotal already reflects any discount — multiplied by the timesheet hours converted to the SO line UoM.

opw-6150555

Forward-Port-Of: odoo/odoo#272910
Forward-Port-Of: odoo/odoo#262524

## Issue
When using the *Auto Plan* feature on a planning slot with a Role and a Project set, a resource which operated on the same project will be chosen if available, without taking into account the Role set on the slot.

## Steps to reproduce
1. Install Project Planning (`project_forecast`)
2. In Planning > Configuration > Roles, create two planning roles A and B
    - Role A: Assign a resource R
    - Role B: No resource
3. Open Planning (Schedule by Resource), and go back a few weeks (to prevent overlaps with potential demo data)
4. Create two new slots:
    1. Set Role B and a random Project P, then click Auto Plan: there should be no available resource (because we didn't set any resource for Role B)
    2. Set Role A and the same Project P, then click Auto Plan: it should assign the resource R assigned to Role A
5. After assigning a resource to the slot for Role A, edit the Open Shift for Role B again and click Auto Plan: **it assigns the same resource R, even though that resource is not assigned to Role B.**

## Cause
The `_get_open_shifts_resources` override in `project_forecast` looks for resources that were assigned to slots related to the same project. It does not filter resources based on the requested role.

https://github.com/odoo/enterprise/blob/885edbc270a86ab76e0a6eff4acb5767c0fe29d1/project_forecast/models/planning_slot.py#L104-L116

This means that resources that are not part of the requested role can be assigned to the slot, as long as the resource operated on another slot for the same project.

opw-6325744

Forward-Port-Of: odoo/enterprise#122352
Forward-Port-Of: odoo/enterprise#122035

### Issue:

Editing the `lot_ids` of a move of a `lot` tracked product from the picking form view leads to wildly unexpected results. This happens only with tracking by `lot` not by serial.

### Concrete Issue 1:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Create and confirm a delivery for 5 units of P
4. Set the quantity of the move to 5 from the Form picking view > save
5. Create and set 2 lots: LOT1, LOT2 on the serial numbers field
6. Save
#### > The quantity of the move has been updated to 2, only the first lot is set and it has been for this quantity of 2

### Concrete Issues 2 and 3:

1. In the settings Enable "Lots and serial numbers", "Storage Locations"
2. Create a storable product P tracked by lots
3. Update the onhand quantity of P:
    - 1 units of LOT001 in Shelf1
    - 2 units of LOT001 in Shelf2
    - 2 units of LOT002 in Stock
4. Create and confirm a delivery for 5 units of P
5. Remove LOT002 from the Serial numbers in the Form picking view > save
#### > The quantity of the move is updated to 1 (only the 1 unit of LOT001 from Shelf2 is kept)
5'. Remove LOT002 and put it back
#### > The quantity is updated from 5 to 2 if you save, only LOT001 is kept.

### Cause of the issue:

The `_onchange_lot_ids` and `_set_lot_ids` methods have been tailored to work appropriately only with `serial` tracking, updating the quantities considering a 1 to 1 quantity, lot matching:
https://github.com/odoo/odoo/blob/c9715982134220aa8fa525d0cf6a8d47eaeb6ed6/addons/stock/models/stock_move.py#L623-L645
However, for lot tracked product the situation is much more subtle to handle.

### Behavior after the fix:

Editing the `lot_ids` on tracked products should adapt the reservation following these rules:
- Existing move lines with a valid lot or lot name should be kept unchanged.
- Removing a lot should delete its related move lines and adjust the move quantity accordingly.
- Each newly assigned lot must be linked to at least one move line of the move.

If the move is expected to bypass reservation (e.g. receipts, final move of a production,...):
- Assignment should be performed, in priority, on an existing free move line.
- If no suitable free move line exists, a new move line should be created with the largest possible quantity that does not cause the total assigned quantity to exceed the move demand.
- If such a quantity cannot be assigned, the new move line should be created with a quantity of 1 in the product.uom_id.

If the move is expected to be reserved (e.g. internal transfer, deliveries,...):
- Each new lot should be assigned from an existing quants with the maximum available quantity to satisfy at best the remaining demand.
- If no available quantity can be assigned from existing quants, the lot should be assigned a minimum quantity of 1 in product.uom_id.

### Additional note on the fix:

Since move that do bypass reservation use a different detailed operation view relying on lot_names form move line rather than lot_id from existing quants it is important to set both the `lot_name` as well as the `lot_id` on move lines for the changes to be visible in the detailed operations view.

### Note:

The current fix populated records on which the `label_production_view_pdf` report was tested (by the test_report) highlighting a template error:
https://github.com/odoo/odoo/blob/a73428187112b3948a11810abae2a3c82c9c7bcd/addons/mrp/report/mrp_production_templates.xml#L187
The value provided to the t-field being something else than a field but rather an or close between two fields.


opw-6173914
opw-5881661

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

Forward-Port-Of: odoo/odoo#272253
Forward-Port-Of: odoo/odoo#263037

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/6b67a45b-6e52-4e02-a827-1aca5d8417ec" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/077bc3ab-bc6e-42a1-85e6-adf778000b92" />

After the fix:
-----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/da2a43e3-01c0-44c5-b529-e73f21825150" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/b658b95f-5bc3-4b7a-9e7c-8b182cab48a0" />


opw-6131231

Forward-Port-Of: odoo/odoo#269716

The previous memory profiler was causing a lot of performance issues.
This is because tracemalloc tracks the allocations that happens at the
python interpreter level by attaching to the cpython allocators. This
first meant each allocation that happens through python has to go
through a callstack while holding the GIL and preventing the thread and
other threads from operating. This callstack does multiple things,
first is walking the allocation back from the current frame up until
the specified frame depth at the start of collection. The other is
updating the internal object that keeps track of the allocations and
what cause them up until now which degrades the performance even more
when the allocator keeps running for a long time. Increasing the frame
depth also means the partitioning becomes even more fragmented in the
internal object and leads to higher memory usage. This in turns means
lower performance as well. The issue becomes more evident when the
overhead of tracemalloc blocks any execution even turning it off
because the gil cannot be released until the full allocation execution
happens.

Currently this would happen on long enough requests or a high enough
depth.

Two PRs were made to try to address this issue.

1- https://github.com/odoo/odoo/pull/251950 : This PR tries the
solution of having a lower frame depth but matching the frames based on
a window of frames so that we can reconstruct an approximation of the
flamegraph, for example: matching window of 2 frames
1 - > 2 - > 3 - > 4
2 - > 3 - > 4 - > 5
would mean that we would match frames 2 and 3 in both stack traces and
append the first frame to the second callstack which would look like
1 - > 2 - > 3 - > 4 - > 5
Neverthless this was deemed to have too big of an assumption in the
building heuristic.

2- https://github.com/odoo/odoo/pull/253120: This PR was supposed to be
introducing memray as a profiler. Memray is the best tool for this
usecase. First because it attaches on the native system allocation
calls, and uses a file to append to on allocations. This solves both of
the issues that we had in the beginning but the issue with memray is
that it's an external tool that was deemed unnecessary to add.

The final solution is this PR:
The PR assumes a heuristic that in worker mode, a single worker handles
one thread which mean that the process memory can be fully attributed
to the request. The heuristic is also based that on a high enough
sampling rate, the delta can be fully attributed to the current frame.
This is a close enough approximation to know where to look but not what
is the actual memory usage by line.

Forward-Port-Of: odoo/odoo#273158
Forward-Port-Of: odoo/odoo#253604

Steps to reproduce
---
1. Pay a website sale order through a payment provider (the payment stays In Process).
2. Reconcile that provider payment with a bank statement line before invoicing.
3. Confirm the delivery and create the invoice for the order.

Issue
---
The invoice is posted but stays open: the linked payment is never assigned to it, even though its receivable line is still outstanding and is even offered in the invoice outstanding-credits widget.

Reconciling the bank statement first fully matches the payment's liquidity line, so the payment moves to the 'paid' state while its receivable line stays open. At invoice posting, _post only auto-assigns payments still in the 'in_process' state, so a 'paid' payment is skipped and its receivable is left unreconciled, leaving the invoice open and requiring a manual intervention.

The matched case was lost in 01b87f1230be, which split the former 'posted' state into 'in_process' (cash not matched) and 'paid' (cash matched) and mechanically renamed this filter to 'in_process' only, dropping the matched payments the old 'posted' used to cover. Restoring 'paid' fixes it while the existing not-reconciled guard still keeps failed payments out.

https://github.com/odoo/odoo/blob/2b89d39f9329ac0fe7a2938595d1f6ee16dc2924/addons/sale/models/account_move.py#L115-L126

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

Forward-Port-Of: odoo/odoo#270315

### Steps to reproduce:

- In the settings enable: Packages
- On the operation type `Delivery Order` set "Set Package Type"
- Create and confirm a delivery for 1 unit of a product P + reserve it
- Got to the barcode app to process the delivery
- Scan your product and click "put in pack"
#### > The put in pack wizard allowing you to set a package type on the new package does not pop up.

### Cause of the issue:

As a general rule of thumb the wizard is suppose to be displayed when the option is enabled and when a package/package type is not already provided to the call:
https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_package.py#L332-L341 https://github.com/odoo/odoo/blob/5dbc448d336c7ff22803ae91d5014eb6d0a07234/addons/stock/models/stock_move_line.py#L1236-L1238 However an override was added to the barcode module so that the wizard is never displayed when the action is launched from the barcode app: https://github.com/odoo/enterprise/blob/673d449f38cd3eff27c44270c8f7edf91d0ecd02/stock_barcode/models/stock_move_line.py#L193-L196

The idea behind this override was that you could provide the package type id via scans and hence that is was not necessary. However, if you click directly on the put in pack button, the wizard still make sense and should therefore be displayed under the same conditions.

opw-6325092

Forward-Port-Of: odoo/enterprise#122308

*: mrp_subcontracting_{dropshipping, purchase}

### Steps to reproduce:

- In the settings: Enable subcontracting, dropshipping
- Create a storable dropshipped product FP with a set vendor for 5$ and subcontracting BOM: 1 X COMP. Value this product in avco perpetual
- Set the component to resupply subcontractor and standard price to 2$
- Create and confirm a sale order for 1 unit fo FP
- Validate the resupply to the subcontractor and then the dropship
> The FP standard price shoul dhave been updated to 5$ + 2$ = 7$
- Create and post a bill from the PO for 10$ rather than 5
#### > The FP standard price should have been updated to 11$ rather than 12$

Cause of the issue:

Posting the bill will call the `_set_value` method to re-evaluate the product in terms of the newly recorded `account.move`: https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/stock_account/models/stock_move.py#L393-L395 Now, the issue is that due to our config, there are two relevant moves linked to the `order_line`: the final move of the subcontracted production (which `is_in`) and the dropship move going from the subcontractor to the customer. When it comes to the subcontracted move, it is appropriately valuated at 12$ by the `_get_value_from_account_move` because of this override which adds the components value via the extra cost since the move has a `production_id`:
https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/mrp_subcontracting_purchase/models/stock_move.py#L14-L38 However, the dropship move will not add this extra cost (as no override sets it to have the same value as the subcontracted production it comes from) so that this move is valuated at 10$. This explains why the value of the avco product is then updated to 11$ since (12 + 10) /2 = 11

Note that the issue is not reproducible in the case of regular subcontracting since in that case the receipt from `subcontractor` to `stock` is not valuated.

opw-6318035

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

Forward-Port-Of: odoo/odoo#273137
Forward-Port-Of: odoo/odoo#272813