Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#270344
Forward-Port-Of: odoo/odoo#257892

### Issue:
Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an import error

Such lines are valid UBL but carry no meaningful value, so they are silently skipped after the fix

### Cause:
After this commit: https://github.com/odoo/odoo/commit/a7f77f3cfc42764328e7da73a60df8d4cafc968f
The `line_extension_amount` was able to go in new parts of the code with a 0.0 value
When `line_extension_amount` is set and `invoiced_quantity` is 0, `quantity` is computed as `subtotal * price_quantity / (...)` which resolves to 0 since `subtotal` is also 0
`price_unit = subtotal / quantity` then divides by zero

### Steps to reproduce:
- Install `l10n_be`
- Import a UBL invoice with a line where `LineExtensionAmount=0`, `InvoicedQuantity=0` and `PriceAmount` is non-zero (You can use the xml on the ticket)

Before the fix, the import failed with an error in the chatter

opw-6234453

Forward-Port-Of: odoo/odoo#271001

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121536
Forward-Port-Of: odoo/enterprise#119525

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423 During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576 Now, the issue is that, `sale_stock_renting` modeule overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Enterprise: https://github.com/odoo/enterprise/pull/121135

opw-6275658

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

Forward-Port-Of: odoo/odoo#271371
Forward-Port-Of: odoo/odoo#271017

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Community: https://github.com/odoo/odoo/pull/271017

opw-6275658

Forward-Port-Of: odoo/enterprise#121135

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Forward-Port-Of: odoo/enterprise#119707

Steps to reproduce:
* Install `l10n_mx_edi` (or `l10n_sa_edi`).
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

Observed behavior:
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

Cause:
* `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`.  However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated.

Fix:
* Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain.
* Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call.

This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic.

opw-6228268

Forward-Port-Of: odoo/odoo#271489

The translate button next to a translatable field saves the record before opening the translation dialog for its id. Since https://github.com/odoo/odoo/commit/a85ca9679e3855936afc66b034d05d75f672dd26 it saves record.model.root rather than the record itself. When the field belongs to a new record still edited inside an x2many, for example an answer added in the survey question popup, saving the root only saves the parent and the new line keeps no database id. The dialog then opens with the id set to false and calls update_field_translations on it, which builds WHERE id = false and the database rejects it with operator does not exist: integer = boolean.

Such a record gets no id of its own, and after a save and reload there is no reliable way to match the saved line back to the one that was clicked, so the dialog can never open for it. A canTranslate getter in TranslationButton returns false for a new record whose model root is another record, which is exactly a line still edited inside an x2many, and the template only renders the button when it is true. The variant in editable lists, where model.root is a list rather than a record, was handled in https://github.com/odoo/odoo/commit/cb34b318004c3ca9db755d8dbbad429609220df3.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app and create a survey
3. Add a question, then in the Answers tab add a line and type a value
4. Click the EN button next to the answer, fill the second language, and Save

=> RPC error operator does not exist: integer = boolean from WHERE id = false

Ticket [link](https://www.odoo.com/odoo/project.task/6260427)
opw-6260427

Forward-Port-Of: odoo/odoo#270410
Forward-Port-Of: odoo/odoo#267781

[FIX] stock,*: properly compute forecast availability after PO resupply scrap
* : mrp_subcontracting_purchase

# How to reproduce
- Enable Subcontracting in the settings
- Create Product A with :
	- Quantity : > 0
	- Routes : Buy & Resupply Subcontractor on Order
- Create Product B
- Create BOM for that Product with
	- BOM Type : Subcontracting
	- Subcontractors : any
	- Component : Product A
- Create a PO for Product B
- Confirm the PO Order
- Use the Resupply smart button
- Click on the gear icons > Scrap
- Scrap Product A

# The problem
A traceback will appear.

# Cause
There are two main ways to get the picking type's code of a move. Either :

- `product_code` which is a related field to `picking_id.picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L174

- `picking_type_id.code` where `picking_type_id` is a computed field :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L283-L287

When we scrap the products, we call the `do_scrap()` function that creates a new
scrap move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L158

When we do so, the create move's `picking_code` wil be the code of the picking type
of the current picking (The subcontractor resupply) :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L151

But `picking_type_id.code` will be different because there is a
`default_picking_type_id` value set in the context by :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/purchase_stock/models/purchase_order.py#L223

In our case, theses values end up not being the same. Later, when we compute the forecast
information of the move, we prefetch virtual available keys and put the moves in a dict
based on those keys.
The computation of the virtual available key is based on the `picking_code` of the move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L488-L490
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L496-L499

When later we try to fetch back the move, we compute the virtual available key based on
`picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L529-L536

But since `picking_code` and `picking_type_id.code` are different, the output
`key_virtual_available` is also different. Essentially, we add the move in the
dict with key A and then try to fetch it back using key B, which gives us a KeyError.

opw-6145887

**Problem:**
When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. and the schedule is flexible and is set to 40h per week. When we open the Attendances app, the expected hours for this employee show 48h.

**Steps to reproduce:**
- Create an employee with a flexible 40h/week schedule and a contract.
- Set employee timezone to Asia/Pyongyang and the working schedule timezone to Europe/Brussels.
- Open Attendances > Overview > Dashboard in week view.
- denominator shows 48h or any other number than 40h.

**Cause:**
In flexible calendars, weekly expected hours are computed by iterating within `[start_dt, end_dt]`. and That logic truncated bounds to `.date()`, assuming `end_dt - 1 second` would always move to the previous day.

That assumption breaks when employee timezone differs from schedule timezone and the employee timezone is far from UTC (like Asia/Pyongyang). so, `end_datetime` is no longer near midnight in local time, so subtracting one second keeps the same date. The loop then includes one extra day and allocates an extra 8h, showing 48h expected instead of 40h in Attendances.

**Fix:**
This change keeps full datetime bounds (instead of truncating to date), so comparisons preserve timezone offset and time of day precision. This prevents the extra day and restores correct weekly expected hours. The original code before this 332cb43 was like this:
```python
                    start_date = start_datetime.date()
                    end_datetime_adjusted = end_datetime - relativedelta(seconds=1)
                    end_date = end_datetime_adjusted.date()
```
this will not work as `.date()` will do the same problem of the extra day allocation.

Affected from 18.0 -> 18.4
Fixed in 19.0+ by this
Backport of https://github.com/odoo/odoo/pull/252847

opw-6171432

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

Forward-Port-Of: odoo/odoo#268346
Forward-Port-Of: odoo/odoo#262805

Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up.

## Benchmarks:

|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|6,262       |0.13s      |68            |0.12s     |68           |
|68,882      |0.60s      |112           |0.58s     |109          |
|432,317     |5.49s      |398           |3.68s     |309          |
|757,702     |15.33s     |1,141         |5.79s     |599          |

[opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)

Forward-Port-Of: odoo/odoo#271677