This is because webclient knows the current value (c), but not the new
available choices, still with the previous one (a, b).

Actually this works correctly if the field is created within a model
class.

```py
if model_cls._setup_done__ and field._base_fields__:
    # the field has been created by model_classes._setup() as
    # Field(_base_fields__=...); restore it to force its setup
    name = field.name
    base_fields = field._base_fields__

    field.__dict__.clear()
    field.__init__(_base_fields__=base_fields)
    field._toplevel = True
    field.__set_name__(model_cls, name)
    field._setup_done = False

    models_field_depends_done.discard(model_cls)
```

It does not works with studio because there are no parent class
(`_base_fields__`), so the if is not reached.

A solution would be to check if the field is a manually created related
and mark the whole model for setup unlike when `_base_fields__` is
present where we only setup this specific field.

opw-6293768

Forward-Port-Of: odoo/odoo#270349

**Issue:**
Currently, an error occurs when users access the `/partners` website page
after upgrading a database with the `website_crm_partner_assign`
module (including demo data) to saas-19.2.

**Root cause:**
This issue occurs because recent changes introduced in PR [1] added a
new template as id `index_layout`. Inside this template, a `t-call` element
was using a nested `t-set` element to define `additional_title`. We were
referencing this `t-set` element in the XPath of the `index` template to
override the value of `additional_title`.

However, recent changes removed the `t-set` from the `t-call` and replaced
it with a direct variable assignment inside the `t-call`. During the upgrade,
the migration script automatically moves the `additional_title` attribute
into `t-call` and removes the `t-set` from the `t-call` (see the script and
related changes in [2]).

As a result, the XPath expression that targets the `t-set` element fails
because the referenced element no longer exists, which causes the error.

**Solution:**
This commit fixes the issue by moving the `t-set` element outside the `t-call`
and passing its value as an attribute of the `t-call` during the upgrade.

The `t-set` element is preserved to maintain compatibility with custom `XPath`
expressions that may target it, prenet XPath target errors after the upgrade.

The upgrade-specific behavior is enabled only when `config.get('upgrade_path')`
is set, allowing the code to detect that it is running in an upgrade context.


[1]: https://github.com/odoo/odoo/commit/711c3baad58f3e0f1dc39cb90eb8176aba91e9dd
[2]: https://github.com/odoo/odoo/pull/235469/changes#diff-29ae6f0bcf846a2fcaffc38fdd0d3b19ea328c133ff4dfe18cc9725715f34dd9


Sentry-7400315548

Forward-Port-Of: odoo/odoo#268864

PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.

The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.

In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.

`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
    MISSING = 0    # function is not present (falsy)
    PRESENT = 1    # function is present but not indexable (not immutable)
    INDEXABLE = 2  # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.

task-6307060

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

Forward-Port-Of: odoo/odoo#270420
Forward-Port-Of: odoo/odoo#270278

Steps to produce:
---
- Install the `Rental` and `Subscription` modules.
- Create a rental product and a subscription product.
- Create a sales order containing both products and set a rental period.
- Confirm the sales order.

Issue:
---
- The rental status badge overlaps the subscription status badge.

Root cause:
---
- The rental status badge uses the position-absolute CSS class to place it at the end of the header. When the subscription status badge is also displayed in the same area, both badges are positioned at the same location, causing them to overlap.
- After [commit], this issue is introduced.

Solution:
---
- Replace position-absolute with float-end so the badges remain right-aligned without overlapping.

[commit]: https://github.com/odoo/enterprise/commit/32ab15dc1f26af0e3d510ec859b1ec428068e9b5

Before:
---
<img width="122" height="64" alt="image" src="https://github.com/user-attachments/assets/e6b47c9e-ed59-4a4b-a95c-0318cc43660e" />

After:
---
<img width="175" height="57" alt="image" src="https://github.com/user-attachments/assets/ea98f7a1-67f6-4b2b-b699-1f2cd3376d8f" />

opw-6295212
---

Description of the issue/feature this PR addresses:
Since [1], studio binary fields uploaded through a form store their filename.
Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses.
Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields.
This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form.

Current behavior before PR:
When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file.

Desired behavior after PR is merged:
Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file.

Task related to this issue: https://www.odoo.com/odoo/project.task/5917543

[1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3
[2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f



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

Forward-Port-Of: odoo/odoo#268014

**Description of the issue/feature this PR addresses:**

When generating a SEPA QR code for a vendor bill payment, the embedded 
amount could occasionally contain excess decimal places instead of 
respecting the currency's expected precision.

This occurs because the `amount` variable in `_get_qr_vals` was being 
converted directly using `str(amount)`. Due to Python's floating-point 
arithmetic, the float value in memory can contain decimal drift.
Directly casting it to a string exposes this drift in the payload.

This commit resolves the issue by replacing `str(amount)` with 
`float_repr(amount, currency.decimal_places)`. This safely bypasses 
the float representation issue, ensuring the string strictly respects 
the currency's configured decimal precision before being injected 
into the QR code.

opw-5504258

**Steps to reproduce:**

- Select company “My Belgian Company”
- Create a 23% purchase tax
- Create vendor bill
   - Select Vendor “BE Company CoA”
   - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73
   - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show

**Current behavior before PR:**

- When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift.

**Desired behavior after PR is merged:**

- The SEPA QR code is generated with the correct number of decimal places.

Forward-Port-Of: odoo/odoo#269190
Forward-Port-Of: odoo/odoo#267293

In 19.0 the /checklist command does not appear in the activity note editor.

The note fields of activities, the schedule activity wizard and activity plan templates were moved to widget="html_mail" by https://github.com/odoo/odoo/commit/2f61560ab45576191394510016c38a7442b95ec8, https://github.com/odoo/odoo/commit/35d673dccdc0f0c2a06cb0732e3148370f035af9 and https://github.com/odoo/odoo/commit/4d3a6156d07dc47bb2399d1907e2a47869827933 to render attachment overviews statically instead of with embedded components. html_mail is made for email bodies, it inlines the content on save and it disables the checklist since https://github.com/odoo/odoo/commit/f94f695ca9fc9a894a837640df2e4160e561f1ab because checklists do not survive the inlining of outgoing emails. The activity note is not an email body, so it gets both side effects for nothing.

Keep the default html widget on these note fields and pass the embedded_components option as false, which is the only part of html_mail the attachment commits needed. The checklist works again, the note is not inlined on save anymore, and the attachment overview still renders statically. The widgets used for real email bodies keep the checklist disabled.

Steps to reproduce:

0. Install the CRM module.
1. Open a lead from the CRM pipeline.
2. Click Activity to open the Schedule Activity dialog.
3. Click inside the Log a note field and type /checklist.

=> Checklist doesn't appear.

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

Forward-Port-Of: odoo/odoo#261071