Steps to reproduce:
===================
1. Edit a job page.
2. Delete every `s_rating` block.
3. Save.

=> Validation Error: Document is empty.

Cause:
======
Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does
`html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving.

The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1])
added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path.

Solution:
=========
Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed.

[1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529

opw-6244892

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

Forward-Port-Of: odoo/odoo#267397

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

Step to reproduce:
1. Install `website_link`
2. Open Website > Site > Link Tracker
3. Type in text into any pre-defined field (Campaign, Medium, Source)
4. Observe that the input is not showing all the typed characters

Issue:
- It's randomly removing characters, for example, type "1234567890" and observe

Cause:
- SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user.

Solution:
- Update searchValue immediately on every raw input event and keep only the search callback debounced.
- Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back 
  to the selected choice label instead of staying visually cleared.

opw-6000540

---

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

Forward-Port-Of: odoo/odoo#255819

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

**Steps to reproduce**
- Use a french company with `l10n_fr_hr_holidays` installed
- Change the duration type of the time off type set as the "Company Paid Time Off Type" in the French Time Off Localization settings to "Half-Day"
- Company Working Schedule:
	- Attendance on a day from 10 to 19, Day Period: Full Day
- Part-time employee Working Schedule:
	- Attendance on the same day from 11 to 12, Day Period: Morning
	- Attendance on the same day from 13 to 19, Day Period: Afternoon
- Create a full day time off for the part time employee on that day, using the time off type set as the "Company Paid Time Off Type" (start am, end pm)

-> Excepted: time off duration is 1 day
-> Actual: time off duration is 0.89 day

**Change**
Now that `request_unit_half` of a leave is a simple related to the `request_unit` of the leave type, it becomes important to not rely on a call to `_get_durations` using the company's calendar to compute the leave's duration, as it may not be fully accurate when the company's working hours and employee's working hours are not aligned.
Continuation of 05e71eb206eb02a8d15708e6fb532a732a767d6d

`_get_fr_date_from_to` is also adapted to take into account multi-day leaves ending in the morning while the employee works in the afternoon (in which case it should not be extended in case the employee doesn't work the next day).

opw-6000011

Forward-Port-Of: odoo/odoo#253059

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