Since https://github.com/odoo/odoo/commit/17893089e8b21c0ecab5e61ed8e2c33f3731b3ac, in certain cases, customers sending large batches of emails to an accounting email alias would report a small number of emails being bounced (ca. 5%).

Context:

1. While processing an email (after matching mail.alias, with the thread going through `message_process`), if an error is uncaught and raised, the mailgate generates a bounce email, as we presume that the email could not be processed correctly.
2. When sending an email with an attachment to an accounting journal alias, depending on the DB configuration, IAP calls for automatic OCR are triggered asynchronously. These calls trigger callbacks from the IAP server, which might hit the DB in parallel while another thread is processing another email. Given their nature, they trigger updates on the relevant account.move, thus triggering downstream computes in the model.
3. When processing an attachment, the account module triggers `_extend_with_attachments`, which tries decoding the attachment in a rollback context (see:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/account/models/account_document_import_mixin.py#L343-L344). If a SerializationError happens during that process (concurrent update), it will NOT use the retry mechanism of the ORM because the error is caught in the `except Exception` block. Instead, it will try to post a message to the record to inform the user that the attachment could not be processed.
4. The commit mentioned above changes the way `_update_sequence_made_gap` works. One side effect seems to be that every time `made_sequence_gap` is re-assigned (even if the value does not change per se), the ORM tries to update the `write_date` on the flagged invoice that generated a sequence gap.

Bug:
Given the above context, emails might bounce unnecessarily for a valid email alias and a valid email with an attachment if:

1. The journal is not using a slash-based sequence pattern (e.g., using "1234" for the naming instead of "INV/2026/1234"). In that case, `sequence_prefix` == "".
2. The first invoice does not start at "1".
3. When sending a burst of simultaneous emails in a multi-worker setup, each thread will trigger `message_process` and downstream accounting computes while processing the invoice. It will also trigger IAP calls and callbacks asynchronously when automatic digitization is activated.
4. Each draft invoice that is created is named "/", meaning `sequence_prefix` == "", which in turn re-triggers the checks in `_update_sequence_made_gap`.
5. This increases the chances dramatically of a serialization error while all the parallel processes indirectly trigger an update on the `made_sequence_gap` field of invoice "1234".
6. Most of the time, the serialization error is not triggered in the thread processing the email, which correctly retries it. But in the few unlucky cases where it is raised in the thread processing the email, it will be triggered in the transaction rollback in `_extend_with_attachments`. While handling the exception, it triggers a second error because it tries to post a message to the record that was just rolled back: -> `ERROR: current transaction is aborted, commands ignored until end of transaction block` is raised in the thread running `message_process`, which in turn triggers a bounce email.

Example logs (simplified):

```
2026-06-12 14:12:15 [Worker-Thread-101] INFO mail_thread: Routing email (1)
2026-06-12 14:12:15 [Worker-Thread-102] INFO mail_thread: Routing email (2)

2026-06-12 14:12:16 [Worker-Thread-101] INFO iap_tools: dispatching /parse
2026-06-12 14:12:16 [Worker-Thread-102] INFO iap_tools: dispatching /parse

2026-06-12 14:12:18 [Worker-Thread-101] INFO iap_tools: Webhook received,
triggering /get_result
2026-06-12 14:12:18 [Worker-Thread-102] INFO iap_tools: Webhook received,
triggering /get_result

2026-06-12 14:12:19 [Worker-Thread-101] INFO odoo.sql_db:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
-> STATUS: OK (Acquired Row Lock)

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
UPDATE "account_move" SET "made_sequence_gap" = true WHERE "id" = 1234
ERROR: could not serialize access due to concurrent update
psycopg2.errors.SerializationFailure: could not serialize access

2026-06-12 14:12:19 [Worker-Thread-102] ERROR odoo.sql_db: bad query:
SELECT "mail_message"."id" FROM "mail_message" WHERE ...
ERROR: current transaction is aborted, commands ignored until end of
transaction block
psycopg2.errors.InFailedSqlTransaction: transaction is aborted

2026-06-12 14:12:19 [Worker-Thread-102] INFO "POST /saas_worker/smtp" 200
-> triggers Bounce email

```

Proposed Fix:
A) We update the conditions in `check_around` to ignore draft invoices when they are the "previous" entity being checked. Only posted invoices should be considered when doing the gap checks.
B) We add some guard clauses to prevent unnecessary writes to invoices that created sequence gaps. Instead of assigning values directly, we store the result of the check and only assign `made_sequence_gap` explicitly if the value is different from the currently stored value. This prevents unnecessary writes to the record if the value did not change.

Note:
- We chose this approach instead of touching `_extend_with_attachments` and the rollback context directly. Mostly to prevent any unforseen side-effects, given that this methods are used in accounting for all attachments. But it might be worth analysing if those methods might be improved to handle scenarios as described above in multi-worker setups + email handling.
- fixing the rollbackable context might tricky because the serialization error happens at the first `cr.commit()` inside the context manager
- raising explicitly with `except psycopg2.extensions.TransactionRollbackError:` in `_extend_with_attachments`
retries the whole request to the `message_process`, which might not be a good idea

OPW-6272396


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

Forward-Port-Of: odoo/odoo#270251

Steps to reproduce
------------------
1. Open a PoS session, e.g. at 1h45
2. Wait a bit and make an order, e.g. at 1h55
3. Keep the session open and go to PoS > Reporting > Sale Details.
4. Select a starting date before the ordre and after the session open, e.g. at 1h50
5. Generate the report.

The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50

Why it's happening
------------------
Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges.

The fix
-------
Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session).

When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range.

opw-6185106

Forward-Port-Of: odoo/odoo#270310
Forward-Port-Of: odoo/odoo#267200

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

Currently, an error occurs when opening the gantt view of work orders.

**Steps to Reproduce:**
 - Install `mrp_workorder` with demo data.
 - Go to `Settings` > `Technical` > `Resource` > `Resources`.
 - Open the `Assembly 1` resource and remove its `working time`.
 - Go to `Manufacturing` > `Operations` > `Work Orders`.
 - Switch to the `Gantt view`.

`KeyError: 22`

when the user opens the Gantt view, the system checks the unavailability of work centers and employees 
based on their resource calendars. While computing unavailable intervals for resources [1], resources 
without a calendar are flexible resources. If no leave interval exists within the specified start and end 
range that matches the domain, the resource is not included in the result [2]. when updating the 
unavailable intervals dictionary [3], the resource is missing. As a result, when it later tries to access 
the unavailable intervals for that resource, it raises an error [4].

This commit prevents the error by safely handling resources that are not present in the unavailable 
intervals dictionary by using an empty list instead.

[1]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L186

[2]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_calendar.py#L532-L536

[3]:https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L187

[4] https://github.com/odoo/enterprise/blob/47f2e9e88fa0bbb8852fe7734c6bece4dca8b9d0/mrp_workorder/models/mrp_workorder.py#L692-L694

sentry-7525704808

Forward-Port-Of: odoo/enterprise#119385

### What & why

`odoo db load` always calls `restore_db(..., copy=True)`, which forces the
generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is
the right default when *duplicating* a database, but it breaks the intended
behaviour when *moving* a database between servers: Enterprise subscription codes
are registered against the database UUID, so regenerating it deregisters the
moved database.

The web database manager already lets the user choose between copying and moving
(the `copy` flag of the `/web/database/restore` route), but the CLI exposed no
equivalent and forced a copy unconditionally. The CLI is the better tool for
server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits
and can run unattended or interactively.

### Steps to reproduce the current limitation

1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID)
2. On server B: `odoo db load mydb mydb.zip`
3. `database.uuid` has changed → the subscription is deregistered

### Fix

Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`,
keeping the original UUID. The default remains `copy=True`, so existing behaviour
is unchanged.

```sh
odoo db load mydb mydb.zip          # unchanged: restore as a copy (new UUID)
odoo db load --move mydb mydb.zip   # new: restore as a move (keep the UUID)
```

### Backport request

This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well.
Those are precisely the versions that ship the `odoo db` CLI subcommand, so the
fix is applicable to all of them — which is why the backport range is 16.0 → 19.0
and stops at 16.0.

Forward-Port-Of: odoo/odoo#268700
Forward-Port-Of: odoo/odoo#268501

**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
---

**Problem:**
On a rental order, the sales order / quotation PDF no longer shows the pickup and return dates. The line description only displays the rental duration (e.g. "2 Days"), so the actual dates are missing from the printout.

**Steps to reproduce:**
1. Create a rental order with a rentable product and pickup/return dates
2. Print the order (Print > Quotation / Order)
3. Observe the PDF shows only the duration, with no pickup/return dates

**Current behavior:**
Neither the rental dates (removed from the description) nor any pickup/return field appear on the PDF.

**Expected behavior:**
The pickup and return dates are shown on the rental order PDF.

**Cause of the issue:**
The rental line description was intentionally reduced to only the duration (`_get_rental_duration_description`), the actual dates being meant to appear as dedicated Pickup/Return fields. This was added to the customer portal (`sale_rental_portal_details` inherits `sale.sale_order_portal_content`) but the equivalent was never added to the `sale.report_saleorder_document` PDF report, so the dates disappeared from the printout.

**Fix:**
Inherit the sale order report to render the order-level pickup and return dates for rental orders, mirroring the existing portal presentation so the PDF and the portal stay consistent.

opw-6268640

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

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#120790
Forward-Port-Of: odoo/enterprise#118714

Steps to reproduce
---
1. Set an employee to work 8 hours per day.
2. Open the timesheet timer in the systray, type a duration like 8:00 and save.
3. Open the My Timesheets grid for that day.

The day is marked as overtime (yellow) even though only 8 hours were logged.

Issue
---
While the entry is open the timer keeps running and, every second, writes the elapsed time into unit_amount down to the second. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L89-L102

When the duration is set by hand, the save skips the usual rounding and keeps the value as it is. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L120-L132

So the clean 8:00 the user typed gets a few extra seconds from the next timer tick (8h 1s, stored as 8.000277) and is saved with them. The seconds are hidden in the HH:MM display but are enough to push the day above its working hours, so the grid paints it as overtime. This timer form is new in saas-19.2 (c3dac6ccdb5), which is why earlier versions are not affected.

The fix ignores timer ticks once the duration has been set by hand, so the typed value is kept.

opw-6180676
---

Forward-Port-Of: odoo/enterprise#120601

The website appointment calendar fills availabilities one month at a time and the update_available_slots route maps the calendar month index to an absolute month from datetime.now(). This only matches the displayed months when the first one is the current month. When the first bookable slot is later, a punctual appointment starting in a future month or any appointment whose "at least X hours before start time" lead time pushes the first slot past the current month, navigating forward requests the wrong month and the reached month renders empty.

In update_available_slots, take the lead time into account when computing the reference month so it lands on the first displayed month: the start datetime for a punctual appointment starting in the future, otherwise now plus the minimum schedule hours. The navigated month index is then added to that reference. This extends https://github.com/odoo/enterprise/commit/f0e5b14a823cf97218f4094d287a328e2744fd73 which only handled the future start datetime.

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type, set Schedule to Weekly and Allow Bookings to On specific dates with a range ending a few months out
3. Set the "at least N hours before start time" field to 360
4. Save and click the Preview button in the header
5. Pick a resource or staff member to reach the calendar
6. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#120715

### Steps to reproduce:
- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 2 x COMP (lot tracked)
- Put a lot for 6 units in of COMP in stock
- Create and confirm an MO for 5 units of FP
- Set the quantity producing on the MO to 1, requiring 2 of the 6 available units of COMP
- Validate the MO and create a backorder for the remaining quantity.
#### > The consumed qty on the main MO is of 0 units rather than 2.

### Cause of the issue:

Since the component is tracked, and since the pbm move was backordered, the move quantity will not be automatically set when setting the `qty_producing`:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1405-L1411 And in particular, the move is not picked as it would if the product was untracked or if the pbm move was not backordered:
https://github.com/odoo/odoo/blob/a1bcd917846493d08dd02b63e6110078ff5156a3/addons/mrp/models/mrp_production.py#L1421-L1427 And, since the move will not be picked at any other point in this flow, the move will be unreserved during the `button_mark_done`: https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L2216 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1895-L1896 https://github.com/odoo/odoo/blob/7c35e183d6cc33a6e5d20e5e97ffef79e03b49d4/addons/mrp/models/mrp_production.py#L1901

opw-6128575

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

Forward-Port-Of: odoo/odoo#269535
Forward-Port-Of: odoo/odoo#269235

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

*: l10n_{ar,co,in,pe,uy}_pos

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.


**Note:**
Another possibility is to re-inherit for each localization the new
standalone view, but this fix would need to update the module to work,
while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really
want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0bd77659b87359f2ca8763702462aaf92R26

opw-6244777 (many more)

Forward-Port-Of: odoo/odoo#268158

*: br,cl,ec,gt,it,ke,mx

**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.

Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.

**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).

Add a test to prevent future regression.

**Note:**
Another possibility is to re-inherit for each localization the new standalone view, but this fix would need to update the module to work, while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really want to go back to each localization needing to inherit backend views.

[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0>

opw-6244777 (many more)

Forward-Port-Of: odoo/enterprise#119316