Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/enterprise#125893
Forward-Port-Of: odoo/enterprise#124686

Currently, an error occurs when a user uploads a document.

**Steps to Reproduce:**
 - Install the `ai_documents` module.
 - Go to `Documents` and create a `folder`, or use an `existing one`.
 - Open the `folder` > click `Actions` > `Auto-sort`, and `save`.
 - Uninstall the `ai_documents` module.
 - Go back to `Documents`, open the `same folder`, and `upload any document`.
 - Error is logged in the `terminal`.

`ValueError: Invalid field documents.document.ai_sortable in condition ('ai_sortable', '=', True)`

When the ai_documents module is installed and the user enables Auto-sort for a folder [1], an 
automation rule and its linked server action are created [2] (if they do not already exist). 
Whenever a document is uploaded to that folder, the automation rule triggers the server action, 
which runs the AI prompt to classify and sort the document.
However, when the ai_documents module is uninstalled, the related automation rule and server 
action are not removed. As a result, uploading a document to the same folder still triggers the 
automation rule. While evaluating its domain, it attempts to access the ai_sortable field, which 
no longer exists because it is defined by the ai_documents module, raise the error [3].

This commit ensures that uninstalling the ai_documents module removes the related automation 
rules. The linked server actions are then deleted automatically through the field's ondelete='cascade' [4].

[1]: https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/wizard/ai_documents_sort.py#L100

[2]- https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/models/documents_document.py#L313-L330

[3]- https://github.com/odoo/enterprise/blob/c6d3efb164a23d555e30d0f0f7de3de2ef1d08d3/ai_documents/models/documents_document.py#L321

[4]: https://github.com/odoo/odoo/blob/2cb2f33c871bf83c74098ada568e167aad24f2a5/addons/base_automation/models/ir_actions_server.py#L17


sentry-7607903354

Forward-Port-Of: odoo/enterprise#124488

Steps to reproduce the bug:
- Create a BOM for product P1 with one work order WO1
- Create 3 quality points linked to WO1 via the `operation_id` field
- Confirm a manufacturing order for P1:
    - 3 quality checks A → B → C are generated
- Open the shop floor for the work order:
    - Observe that all 3 quality checks are displayed
- Delete quality check B (the middle one)
- come back to the shop floor for the work order:
- Observe that quality check C is no longer displayed in the shop floor

Problem:
After deleting check B, check C disappeared from the shop floor. Quality checks are stored as a doubly-linked list via the `next_check_id` and `previous_check_id` fields on `quality.check`. The shop floor JS (`mrp_display_record.js`) traverses this list starting from the check with no `previous_check_id`, then follows `next_check_id` until the chain ends. When check B was deleted, it nullified the FK references pointing to it, leaving check A with `next_check_id = False` and check C with `previous_check_id = False`. The traversal from A therefore stopped immediately, and C was never reached.

No `unlink` override existed on `quality.check` to repair the chain before deletion.

Solution:
Added an `unlink` override that, before deleting each check, reconnects its predecessor and successor: if the deleted check has both a previous and a next, `prev.next_check_id` is set to `next` and `next.previous_check_id` is set to `prev`, preserving a valid chain for the remaining checks.

opw-6369298

Forward-Port-Of: odoo/enterprise#124118

[FIX] mrp_workorder_plm: avoid singleton traceback when matching BOM operations
**Issue**
Adding a step in a manufacturing order with two operations that are too similar
could lead to a traceback when proposing an improvement from the Shop Floor.

**Steps to reproduce**
- Install the Product Lifecycle Management app.
- Create a BOM for any product with two operations that:
	- Have the same name and work center
	- Have no variant
- Create and confirm a Manufacturing Order for that product.
- Open the Shop Floor view.
- Click the gear icon -> Update Instructions -> Improvement Suggestion -> Add a Step -> Propose a Change.
-> A traceback occurs

**Cause**
When adding a step:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L10
It tries to find the corresponding operation in the ECO's new BoM.
This relies on `_get_sync_values()`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_plm/models/mrp_routing.py#L9-L13
Because two operations share the same name, work center, and no variant, both match the filter:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L39
This results in a singleton error when accessing `operation.id`:
https://github.com/odoo/enterprise/blob/1c02615b73a2b4fb9f1ab91167a3c8d7c9ac824c/mrp_workorder_plm/models/mrp_workorder.py#L42

opw-6241880

Forward-Port-Of: odoo/enterprise#123673
Forward-Port-Of: odoo/enterprise#119404

Currently, an error occurs when a user removes the Tax Treatment Category of an Australian employee.

Steps to Reproduce:
 - Install the `l10n_au_hr_payroll` module with demo data.
 - Switch to an `Australian company`.
 - Open any `Employee` > `Payroll` > remove the `Tax Treatment Category` value.

`UnboundLocalError: cannot access local variable 'code' where it is not associated with a value`

After the [change] in selection field behavior, users can clear the value of the field. When the 
user removes the Tax Treatment Category value, the system computes the tax treatment 
code [1]. During this process, if no condition matches, the code variable is not initialized. 
Converting this uninitialized variable to a string [2] raises an error.

This commit ensures that when the tax treatment category is not set, the tax treatment code is 
set to False with an early return. Since the tax treatment category is required field and compute 
the correct tax treatment code, once the category is set.

[change]: https://github.com/odoo/odoo/pull/214422/changes/8d2a42ac419fdf7943a0c11beb8c5de6c6f85bef

[1]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L450-L451

[2]- https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/l10n_au_hr_payroll/models/hr_version.py#L515

No task ID

Forward-Port-Of: odoo/enterprise#124067

Steps to reproduce:
===================
1. Create a subscription product, allow one-time sale, sale price 5
2. Add a recurring price 10/month
3. On the pricelist, add an advanced rule: -10% for the monthly plan
4. Open the shop page and look at the product tile

Cause:
=======
On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`.

In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price

With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price.

Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan.
=> Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9).

Solution:
=========
The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`.

opw-6307398

Forward-Port-Of: odoo/enterprise#120872

Currently, an error occurs when processing Ecuadorian EDI invoices that
use taxes from the `Special Consumptions (ICE)` tax group.

**Steps to reproduce:**
- Install `l10n_ec_edi` and switch to an EC Company.
- Create a new tax with the `Tax Group` set to `Special Consumptions (ICE)`.
- Create an invoice using this tax.
- Confirm the invoice and click `Process Now`.

**Error:**
```
  File "/home/odoo/odoo/enterprise/saas-18.4/l10n_ec_edi/models/account_edi_format.py", line 373, in _l10n_ec_get_base_lines
    code_percentage = L10N_EC_VAT_SUBTAXES[tax_data['tax'].tax_group_id.l10n_ec_type]
KeyError: 'ice'
```

**Root Cause:**
At [1], non-VAT tax groups such as `ICE` are explicitly not supported
and are not included in `L10N_EC_VAT_SUBTAXES`.

At [2], the code assumes that every Ecuadorian tax group exists in
`L10N_EC_VAT_SUBTAXES` and directly indexes the mapping using
`tax_group_id.l10n_ec_type`. When an invoice uses an `ICE`
tax, causing an error.

**Fix:**
This commit prevents errors by using the tax's `Code ATS` as the
`codigoPorcentaje` value and the tax's `amount` as the `tarifa` in
the XML when the tax group is not present in `L10N_EC_VAT_SUBTAXES`.
(Confirm with the PO [here], just to fix it from 18.4, that the problem is 
that it is not working on the versions where we already introduced the feature.)

[1]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_move.py#L17-L38

[2]:
https://github.com/odoo/enterprise/blob/a388b9298268eead53ffa9d33bff7e1927dae33c/l10n_ec_edi/models/account_edi_format.py#L372-L377

[here]:
https://www.odoo.com/mail/message/1121493378

opw-6373984
opw-6430589
opw-6423812

Forward-Port-Of: odoo/enterprise#123918

The bugfix introduced in https://github.com/odoo/odoo/commit/01d11a770f89c391f7c6a2c46a3d770d10afb428 made it so that "personal" outgoing mail servers are blocked/ignored from being used in email marketing as dedicated servers.

In doing so, it missed the fact that while in *Email Marketing > Settings*, the "Dedicated Server" picker now correctly ignores personal OMS entries, the selection widget for `mail_server_id` in `view_mail_mass_mailing_form` still let's you manually select a OMS with an owner set. As there is not warning or an explicit error, this can lead to accidental miss configurations on an email marketing campaign, where the selected OMS will be actually ignored by the backend.

To align the changes introduced by the bugfix, we add a search domain to the selection field, so that only OMS with `('owner_user_id', '=', False)` will be presented as a choice.

OPW-6388562

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

Forward-Port-Of: odoo/odoo#278918
Forward-Port-Of: odoo/odoo#278595

Issue caused because of https://github.com/odoo/odoo/commit/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd Steps to reproduce-
Create db with demo and install l10n_in
Create a new company for India (other than IN Company) Go to Settings -> Accounting/Invoice Tab -> Enable Ewaybill

traceback
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5385, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: not enough values to unpack (expected 1, got 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 273, in __call__
    response = serve_db(request)
               ^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/http/router.py", line 380, in serve_db
    registry = Registry(request.db)
               ^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 105, in __new__
    return cls.new(db_name)
           ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 217, in new
    cr.rollback()
  File "/home/odoo/odoo18/community/odoo/sql_db.py", line 568, in rollback
    with rollbacking:
  File "/home/odoo/.pyenv/versions/3.12.0/lib/python3.12/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1004, in rollbacking
    self.restore_state()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 1067, in restore_state
    self.reset()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 912, in reset
    self._reset_registry_change()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 832, in _reset_registry_change
    registry._setup_models__(cr)
  File "/home/odoo/odoo18/community/odoo/tools/func.py", line 67, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/registry.py", line 422, in _setup_models__
    env.invalidate_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 395, in invalidate_all
    self.flush_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 413, in flush_all
    self._recompute_all()
  File "/home/odoo/odoo18/community/odoo/orm/environments.py", line 406, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 6462, in _recompute_field
    field.recompute(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2042, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2012, in apply_except_missing
    func(records)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 2066, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/odoo18/community/addons/mail/models/mail_thread.py", line 498, in _compute_field_value
    return super()._compute_field_value(field)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 4387, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/odoo18/community/odoo/orm/fields.py", line 82, in determine
    return needle(*args)
           ^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 228, in _compute_document_partners_details
    seller_buyer_details = ewaybill._get_seller_buyer_details()
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 185, in _get_seller_buyer_details
    return move._get_l10n_in_seller_buyer_party()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in/models/account_invoice.py", line 629, in _get_l10n_in_seller_buyer_party
    self.ensure_one()
  File "/home/odoo/odoo18/community/odoo/orm/models.py", line 5388, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move()
```
In this commit, we resolve the above traceback

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

Forward-Port-Of: odoo/odoo#276216

Issue
-----
International deliveries for fractions of items (eg 500g of a product sold by kg) are rejected by Sendcloud.

Steps to reproduce
-----
- Setup Sendcloud
	- Fedex international
- Create a product
	- weight: 1kg
	- valid hs code
- Create a contact (outside EU if the company is in EU)
- Deliver 0.5 of the product to the contact

> Error "... parcel not returned from Sendcloud"

Cause
-----
Sendcloud returns he folloing error:

> "The total weight for declared items exceeds the total weight set for the shipment."

This is because the `weight` set on the shipment

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L449-L464

corresponds to the weight of the package, whereas the weight set on the description of the product in `parcel_items` corresponds to the weight of one "full" unit of the product.

https://github.com/odoo/enterprise/blob/99a13453cac8a7a4677cef3df8896329c90c9e99/delivery_sendcloud/models/sendcloud_service.py#L327-L335

We cannot change the quantity in `parcel_items` to match the actual delivered one because the field should be an integer.

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-parcel-items-items-quantity

The price is also off, because it gets taken from the `move_line`, so it reflects the price of the actual quantity and not a "full" item.

https://github.com/odoo/odoo/blob/208a8a6a5adb8ec1f2710453c2ee3b54c55a9f1e/addons/stock_delivery/models/delivery_carrier.py#L235

Note that this issue is common to **all UoM types**.

Solution
-----
Since we cannot change the quantity, we can instead adapt the description and weight sent in `parcel_items`. For example, sending 300g of sugar, we would send
- description: "Sugar (0.3 kg)"
- weight: "0.300"

-----
Ticket:
opw-6346330

Forward-Port-Of: odoo/odoo#277440

Description of the issue this commit addresses:

When a member of the Invoicing group tries to create a payment trough the L10nPlAccountPaymentRegister wizard, upon clicking "Create Payment", an AccessError is thrown. Invoicing group members should be able to handle payments so this is an issue.

---

Steps to reproduce:

1. Make sure sale_management and l10n_pl_bank_verification are installed.
2. Create a new user with "Invoicing" Accounting group.
3. Create a new sales order with said user (any customer, any product)
4. Confirm the quotations and, from its form view, "Create Invoice".
5. Confirm the invoice and, from its form view, "Pay".
6. Upon clicking "Create Payment", an Access Error is thrown.

---

Desired behavior after this commit is merged:

This commit makes sure an Invoicing group member is able to create the payment withtout AccessErrors being thrown.

---

task-none
feedback from: https://github.com/odoo/odoo/pull/267992

---

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

Forward-Port-Of: odoo/odoo#279033
Forward-Port-Of: odoo/odoo#270008

When refunding an order that had a fixed-amount global discount, the refunded total was inflated: e.g. a 65.00 order (80.00 - 15.00 fixed discount) was refunded as 95.00 instead of 65.00. On the refund order `amount_paid` then differed from `amount_total`, so the POS session's closing entry could not balance; `_validate_session` rolled back and no `account.move` was created, leaving the session closed with no accounting.

When a refund is created, the product lines are negated and the discount line is excluded, then `pos_discount` re-applies the global discount to the refund order through `applyDiscount`. For a fixed amount, `reduce_base_lines_to_target_amount` targets an absolute value and does not follow the sign of the (now negative) base, so the discount keeps the sale sign. Percentages scale with the base and are not affected.

Negate the fixed discount amount when the destination order is a refund so it mirrors the negative base. The stored `discount_value` is left unchanged so the auto-resync of the discount stays idempotent.

opw-6400738

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

The `Quantity On Hand` field doesn't always show up directly

To reproduce the issue:
1. Create a product template without any tracking
2. Switch the tracking to 'Quantity'

Error: if we don't save the form, the `Quantity On Hand` field doesn't show
up. That's terrible and reminds us the so old click-to-edit Odoo 14.

The field `qty_available` is wrapped into a `div` container that is
invisible in some conditions, and one of them is based on `is_storable`:
https://github.com/odoo/odoo/blob/913efdfe9af3d1dd75a0687a72a7ec5ecb7297fe/addons/stock/views/product_views.xml#L194-L195

The field is a computed one and will be set to `False` under some
conditions in its compute method. The compute will never mark it as `True`,
which is a first issue. Second, in the above use case, it only changes to
`True` when saving thanks to the inverse method of the `tracking field`:
https://github.com/odoo/odoo/blob/1fdc147b75b1746f85d810f1288bd1d632166083/addons/stock/models/product.py#L1003-L1005
This therefore explains why the `Quantity On Hand` doesn't show up during
step 2: it's an onchange mechanism, the inverse methods are not triggered.

A similar issue will also happen on a variant form, but because of another
reason. This time we need to look at the field `qty_available` itself, which
depends on `show_qty_update_button`:
https://github.com/odoo/odoo/blob/913efdfe9af3d1dd75a0687a72a7ec5ecb7297fe/addons/stock/views/product_views.xml#L200
The field is a computed one and the method is missing one dependency.

No ticket
Discovered during PR review of opw-6316788

Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:

    Internal compiler error #12345: error mmapping datablock to 30283637

Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.

The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.

While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.

Changes:
 - Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
 - Bump the base image from Debian Bookworm to Trixie.
 - Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
 - Upgrade NSIS to the latest release.
 - Refactor the NSIS installation step to remove the hardcoded version from `package.py`.

This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.

Forward-Port-Of: odoo/odoo#278681
Forward-Port-Of: odoo/odoo#278378

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Bank Journal** and go to the **Inbound Payment Methods** tab.
* Add the **Manual** payment method multiple times and give each payment method line a different name.
* Go to **Customers → Payments** and create a payment using any of these payment method lines.
* Print the **Payment Receipt** from the gear menu.

**Observed behavior:**
* The receipt always displays the **Manual** payment method name.
* The custom name configured on the selected payment method line is ignored.

**Cause:**
* The report retrieves the payment method name from `account.payment.method`.
* However, the displayed name is configured on `account.payment.method.line`, so the report always shows the generic payment method name.

**Fix:**
* Read the payment method name from the selected `account.payment.method.line`.
* The payment receipt now displays the configured payment method line name.

opw-6395829

Forward-Port-Of: odoo/odoo#277104

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3dd56325d8 [REL] 19.3.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7d7ac96719 [FIX] ui_sheet: `getCellWidth` getter for non-active sheet [Task: 6409426](https://www.odoo.com/odoo/2328/tasks/6409426)
https://github.com/odoo/o-spreadsheet/commit/476b1731db [FIX] pivot: prevent drag & drop in pivot side panel [Task: 6268403](https://www.odoo.com/odoo/2328/tasks/6268403)
https://github.com/odoo/o-spreadsheet/commit/186ab9ce81 [FIX] dashboard: clickable cell is not triggered by a right click [Task: 6365823](https://www.odoo.com/odoo/2328/tasks/6365823)
https://github.com/odoo/o-spreadsheet/commit/2a4f4991cb [FIX] calendar chart: skip missing value tooltips [Task: 6276800](https://www.odoo.com/odoo/2328/tasks/6276800)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**

1. Enable debug mode and add a snippet.
2. Add a YouTube video with options like autoplay enabled.
3. Double click the video or use "Replace Media".
4. A traceback occurs while reopening the video options.

**Root Cause:**
When the media dialog is reopened on an existing video,
`syncOptionsWithUrl()` derives each switch option's value from the URL:
`value = this.state.urlInput.includes(urlParameter)`, which stores
Boolean `true` when e.g. autoplay is enabled. Similarly, toggling an
enabled option off stores Boolean `false`

The `value` prop was already `Boolean` but after commit https://github.com/odoo/odoo/commit/ae894892e048b
 we declared the prop as `value: { type: String, optional: true }` on
`VideoOption`. In debug mode, OWL validates props and throws
"Invalid props for component 'VideoOption': 'value' is not a string"
when it receives those booleans. The declaration does not match the
values the component actually receives.

**Fix:**
Normalizing the state to strings at the source would require rewriting
the option-state logic for no behavioral gain. Since booleans are
produced deliberately by two code paths, the honest prop type for value
is `[String, Boolean]`.

task-6233423

Forward-Port-Of: odoo/odoo#266304

While preloading chart template data, if an account already exists in the db but has `active=False`, it is not found because archived records are excluded from the [`_search`].

As a result, the load attempts to create a new account. During creation, the Python constraint [`_ensure_code_is_unique`] searches with `active_test=False`, finds the archived account with the same code, and raises a ValidationError:
```py
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 735, in _load_data
    'noupdate': True,
                     ^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4519, in _load_records
    records = self._load_records_create([data['values'] for data in to_create])
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 4426, in _load_records_create
    records = self.create(vals_list)
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1057, in create
    records._ensure_code_is_unique()
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/account_account.py", line 1135, in _ensure_code_is_unique
    raise ValidationError(
odoo.exceptions.ValidationError: Account codes must be unique. You can't create accounts with these duplicate codes: 1.1.1.02.003, 1.1.1.02.004
```

Steps to reproduce:
- In a `v19.0` database, install `l10n_ar` with demo data.
- The accounts with codes `1.1.1.02.003` and `1.1.1.02.004` are created by [`_create_outstanding_accounts`].
- Archive those accounts and upgrade to `v19.2`.
- During the upgrade, [`_get_latam_check_outstanding_account_account`] attempts to create new accounts with the same codes, triggering the duplicate code validation.

tbg-2840

[`_search`]: https://github.com/odoo/odoo/blob/619d8ce9f31349ed06b11ead4988a4a1d9ca6bdd/addons/account/models/chart_template.py#L438
[`_ensure_code_is_unique`]: https://github.com/odoo/odoo/blob/19.0/addons/account/models/account_account.py#L1133
[`_create_outstanding_accounts`]: https://github.com/odoo/odoo/blob/06a46b083fde5688d71c5602553316c9e7160b6a/addons/account/models/chart_template.py#L925C9-L949
[`_get_latam_check_outstanding_account_account`]: https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_latam_check/models/account_chart_template.py#L60-L76



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

Forward-Port-Of: odoo/odoo#279313
Forward-Port-Of: odoo/odoo#279092

Steps to produce: 

1) Install Manufacturing & enable "Work Order Dependencies" in the settings
2) Make a new BOM with 2 operations
3) Check "Operation Dependencies" in the miscellaneous tab on the BOM's form view.
4) Configure the first sequential operation to be blocked by the second
5) Make and confirm an MO using this BOM
6) Uncheck "Operation Dependencies" on the BOM
7) Press "Plan" on the MO, a validation error is thrown stating "You cannot create cyclic dependency."

Issue occurs because after the MO is confirmed the blocked_by_workorder_ids field for mrp.workorder records is set based on the order manually configured on the BOM (operation 1 is blocked by operation 2). After the BOM is edited to have allow_operation_dependencies = false, then Odoo uses the default sequential ordering when planning the operations (operation 2 is blocked by operation 1). Since the old ordering is never cleared, a cycle is created unintentionally. 

This PR resolves this issue by clearing the blocked_by_workorder_ids field on mrp.workorder records. 

opw-6334271

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

Forward-Port-Of: odoo/odoo#278255
Forward-Port-Of: odoo/odoo#275154