This PR alignes appointment and pos_appointment as the applications must display the same views and data as they have the same purpose:

- The kanban view has been added in appointment to see the appointments per status and to easily update that attribute. A popover is displayed when clicking on kanban's records in order to show quickly essential information as in the gantt view. 
- The graph and privot views have been added in appointment to allow a better reporting.
- The design of the popovers of the gantt and kanban views in appointment and pos_appointment have been updated. In appointment, the update of the appointment status is no longer done from a field but from buttons as they are more visible. As the popovers needs to display the same data, design and use the same logic, a unique popover as been created and used by those views.
- The design of the form for the quick creation in pos_appointment has been aligned with the one in appoitment. To give more visibility to the appointment status, it can be updated using buttons in the footer. The form in pos_appointment is bigger than in appointment as it is used by touchscreens.   


Community PR: https://github.com/odoo/odoo/pull/287457
Upgrade PR: https://github.com/odoo/upgrade/pull/11154

Task-6185312

RATIONALE

In some cases (luxury, big corporate company) people want to be able to
review all messages generated by Odoo that are sent to the customers.
This is important when branding / copy writing is considered valuable
(e.g. "Your ticket has been closed" → "We are happy to announce that your
care ticket ...").

Currently we have several ways of generating them
 * using a mail.template (used either as template.send_mail() in code, either
   due to tracked changes, either with manual usage of templates);
 * message_post → post a body, and if recipients to notify by email content
   is encapsulated in an email layout
   -> can be manual (chatter), message_type being email (incoming email) or
      comment (user input in chatter)
   -> can be automatic (calling message_post in code), generally with
      message_type being notification, auto_comment
 * message_post using rendered body based on a qweb view (in code), see
   message_post_with_source
 * mail.mail manual creation → code only (as only admins can create mail.mail)
 * message composer
   -> may be used to post a message, on a single record or in batch, based
     on a template or using custom body
   -> may generate mail.mail in batch (standard mailing usage)
 * mass mailing → uses message composer to generate emails

It is currently not possible to review through interface all content that
might be sent to clients automatically: mail.templates can be found and
modified, but strings inlined in code cannot (only through code or
customization). Views can be found but there is no easy way to find them
in the UI.

SPECIFICATION: AUDIT LOG

At least give a way to know a mail.mail was created automatically / manually
 * when a template is used, keep mail_template_id on message. Note that if
   content was modified manually, template_id is still propagated;
 * when it is generated through a mass mailing, keep mailing_id on mail.mail
 * when it is generated automatically by message_post in code → message_type
   is 'notification', which is ok
 * when it is generated by users → message_type is 'comment', which is ok
 * add a flag on qweb views used in posting process so that we can filter and
   find them easily. Add a menu entry below "Email Templates" to find them


Task-6368610 [mail] Track content source
Part of Task-6260135 [mail] Ability to review outgoing content

As of commit 4588e939, payment data records are queued and processed serially by a dedicated cron. This allowed payment requests to be isolated from the processing step and, by design, eliminated race-condition rollbacks on payment transactions. However, the post-processing remained a separate asynchronous step, still run on demand when customers reached the `/payment/status` page and from cron triggers scattered across provider and app modules for backend flows. This had several undesired side effects:

- Backend business logic (captures, refunds, subscription invoicing, POS order confirmation, etc.) was forced to wait for a free cron worker or for the next scheduled run.
- Customers had to wait out the 10-second timeout when the notification that should have triggered the redirect was missed (sent before the page had subscribed to its channel) or premature (sent before the transaction had been post-processed).
- The post-processing cron had to run at a relatively high frequency, with only 10-minute intervals by default.
- Transactions that had several state updates before they could be post-processed would only be post-processed for their last state change.
- The extra step added overhead to the overall transaction processing cycle.

This design was intentional, as it allowed payment requests and the processing step to be isolated from the much more failure-prone post-processing step. Indeed, it executed fragile business logic (e.g., posting invoices according to the journal configuration, sending emails) whose failures could have rolled back the transaction and replayed
payment requests. Since this is no longer a risk, the post-processing can be unified with the processing step.

This commit now synchronously post-processes transactions right after they are processed. If the post-processing fails, only that step is rolled back, and the transaction is left to the post-processing cron, which serves as a fallback and retry mechanism. Since the cron is now triggered whenever the synchronous post-processing fails, its interval
is increased from 10 minutes to 24 hours. Satellite flows that confirm transactions without going through the processing (e.g., manual confirmation, refunds already executed on the provider side) now post-process immediately through the new `_try_post_process` helper method, and the asynchronous post-processing triggers scattered across provider and app modules are removed.

The bus notification signaling that a transaction is processed is now sent only after post-processing is completed (succeeded or failed), and carries all the status values needed to redirect the customer. This, in turn, removes the synchronous trigger of the post-processing through a JSONRPC call to the `/payment/post_process` route, further reducing overhead in the payment flow. To avoid missing any notifications, they are now resent upon subscribing to their channel, allowing the redirect to rely on the websocket alone, with the timeout redirect kept only as a fallback.

In addition, the retry window of the post-processing cron is reduced from 4 days to 24 hours. The longer window was meant to give slower providers time to send payment status updates, but processing such updates resets the transaction's `last_state_change` field anyway, so it was never necessary to keep retrying the post-processing for that long. If a transaction fails to be post-processed throughout the retry window, it is left for manual intervention. The cron is also modernized to use the new cron API to report its progress and to stop early when its time budget is exhausted.

task-6240311

See also:
- https://github.com/odoo/enterprise/pull/124474
- https://github.com/odoo/upgrade/pull/10846

## voip: call correlation, number requests, user routing and tenant recovery

Twenty commits on top of master. This is the client side of the phone_service work in
odoo/iap-apps#1854 — the two land together, since the routing call and the user sync now
carry new fields the service expects.

### Call records and events

- **correlate on the conversation, not on a dual-purpose handle** — `control_handle` held the
  PBX conversation identifier for the Odoo provider and the SIP Call-ID for every other one,
  the browser collapsing the two into one value whose nature the server could no longer tell.
  The INVITE now sends `conversation_identifier` apart from `sip_call_id`; `get_or_create`
  matches the conversation first and the Call-ID through the legs after. The column stays —
  it still names a call for the softphone and the push payload — but nothing searches it.
- **one live call per user and conversation** — a call is one user's point of view on one
  conversation, so a second ringing device joins it instead of opening a second record. Every
  event is processed in its own transaction and under REPEATABLE READ neither sees the other's
  insert, so find-or-create could not hold that on its own.
- **give a call placed from a native SIP phone its own record** — a call dialled from Linphone
  left no trace: only the browser ever created a `voip.call`, and there is no browser.
- **never settle a caller number from a reclassified leg** — Wazo swaps `caller_id_number` and
  `peer_caller_id_number` when it reclassifies a callee leg as internal on hangup, so the
  reversal that reads a ringing leg correctly reads a reclassified one backwards.
- **log the whole webhook payload in debug**, behind an `isEnabledFor` check so `json.dumps`
  never runs on a normal server, **accept open-ended WAV data chunks** (both `0x7fffffff` and
  `0xffffffff`, which streamed audio uses and the decoder rejected), and **use UTC in
  astimezone**.

### User routing and preferences

- **let users choose between being forwarded and being woken** — an explicit "On Disconnected"
  setting filling Wazo's chanunavail slot, taken the moment a dial finds no reachable SIP
  contact. It is the same decision as the wake-up token: with nowhere to forward, the PBX
  wakes the browser with a push; with a destination, it hands the call over at once. Settling
  that token is now entirely phone_service's business (odoo/iap-apps#1854), so voip stops
  generating, storing and sending a PBX credential — `voip_pbx_auth_password`, its reconcile
  cron and the `auth` object all go. What stays here is the user's own choice.
- **forward disconnected calls to the phone by default** — mirroring the "no answer"
  fallback: the "On Disconnected" slot is seeded from the user's own number when it is valid,
  never replacing an explicit choice. The three forward slots also merge into a single
  "Forward" section.
- **improve phone number flows** — regular users can request a number from the VoIP status
  menu, through a wizard and a mail template; purchase feedback, DID flags and destination
  selection are polished; and a SIP failure raised when a user cancels an outgoing call before
  its INVITE completes is no longer surfaced as an error, while genuine INVITE errors still are.
- **use a busy hangup as the default busy fallback** — Hangup with the Busy cause and a 5s
  timeout when nothing else is configured.
- **allow users to limit concurrent calls** — a "Ring Concurrent Calls" preference synchronized
  with the PBX, for queue and call group members who would otherwise ring several times at once.
- **synchronize personal mailboxes with Wazo** — mailboxes created during user provisioning
  inherited the context that disables PBX sync and never reached Wazo.
- **restrict voip.extension range** to 3 or 4 digits (100-9999), resolving a disagreement with
  the range phone_service configures on the tenant.

### Registration and provisioning

- **one registration binding per softphone window** — Asterisk identifies a binding by its
  Contact URI alone (`pjsip_uri_cmp`, object named after the URI's MD5); neither `+sip.instance`
  nor `reg-id` is consulted, so every window of a user advertised the same binding.
- **provision Linphone from a QR code** — a `linphone-config:` URI pointing at a signed URL
  serving a remote provisioning file. Linphone scans a provisioning URI, never credentials.
- **let the Odoo provider's settings be edited** (the lock was view-only and cost nothing but
  keystrokes), and **drop the icon from the phone numbers Refresh button**.

### Number requests

- **introduce number requests** — a search that returns no inventory left an administrator
  with no way to obtain numbers that need manual sourcing. A persistent DID number request,
  backed by the advanced order API of odoo/iap-apps#1854, carries a UUID for idempotent
  cross-service correlation, reuses the regulatory requirement groups, and syncs status,
  proposed numbers and comments into a provider-neutral form. Fulfilled numbers join the
  existing DID assignment flow and stay linked to their request. Creating or reviewing a
  request charges nothing; charges apply once the carrier fulfils it.

### Tenant recovery

- **expose a tenant recovery payload** — a versioned description of the complete desired tenant
  configuration, served over a public route that only accepts a short-lived token signed with
  the client secret and scoped to recovery, so a Wazo tenant deleted by accident can be rebuilt.

RATIONALE

In some cases (luxury, big corporate company) people want to be able to
review all messages generated by Odoo that are sent to the customers.
This is important when branding / copy writing is considered valuable
(e.g. "Your ticket has been closed" → "We are happy to announce that your
care ticket ...").

Currently we have several ways of generating them
 * using a mail.template (used either as template.send_mail() in code, either
   due to tracked changes, either with manual usage of templates);
 * message_post → post a body, and if recipients to notify by email content
   is encapsulated in an email layout
   -> can be manual (chatter), message_type being email (incoming email) or
      comment (user input in chatter)
   -> can be automatic (calling message_post in code), generally with
      message_type being notification, auto_comment
 * message_post using rendered body based on a qweb view (in code), see
   message_post_with_source
 * mail.mail manual creation → code only (as only admins can create mail.mail)
 * message composer
   -> may be used to post a message, on a single record or in batch, based
     on a template or using custom body
   -> may generate mail.mail in batch (standard mailing usage)
 * mass mailing → uses message composer to generate emails

It is currently not possible to review through interface all content that
might be sent to clients automatically: mail.templates can be found and
modified, but strings inlined in code cannot (only through code or
customization). Views can be found but there is no easy way to find them
in the UI.

SPECIFICATION: AUDIT LOG

At least give a way to know a mail.mail was created automatically / manually
 * when a template is used, keep mail_template_id on message. Note that if
   content was modified manually, template_id is still propagated;
 * when it is generated through a mass mailing, keep mailing_id on mail.mail
 * when it is generated automatically by message_post in code → message_type
   is 'notification', which is ok
 * when it is generated by users → message_type is 'comment', which is ok
 * add a flag on qweb views used in posting process so that we can filter and
   find them easily. Add a menu entry below "Email Templates" to find them


Task-6368610 [mail] Track content source
Part of Task-6260135 [mail] Ability to review outgoing content

The website builder agent could only touch forms by writing raw HTML,
which produces forms that look right but lose submissions: field names
that are not whitelisted degrade to plain text in the record, a
`send_mail` form missing its hidden `email_to` field gets no
`website_form_signature` at render so every submission raises
AccessDenied, and missing model-required fields fail at submit time.

Teach the agent webforms as structured operations instead of markup:

- "Get Webform Info" lists the available form actions and, per action,
  the model fields a form field can be bound to (from
  `get_compatible_form_models` / `get_authorized_fields`).
- "Edit Webform" applies a validated list of operations (set_action,
  add_field, update_field, remove_field, set_success,
  set_recipient_email) through a new `website_edit_form` client tool.
  Every operation delegates to the community form option plugin (its
  builder actions and shared methods), so the resulting markup is
  exactly what the builder sidebar would produce and the save-time
  machinery (field whitelisting, default `email_to`, label/name sync)
  keeps working. The tool returns a per-operation report and the
  resulting form HTML, following the HTML apply report pattern.
- "Apply HTML to Page" now refuses hand-written webform markup (form
  fields outside a form, webforms without a form-enabled
  `data-model_name`, unnamed inputs) and points the agent to the
  webform tool. Canonical form snippets and existing forms carried
  along in a zone replace pass untouched.
- The Website Builder skill documents the workflow: insert a form
  snippet unchanged, then configure it with the webform tools.

  task-6251785

Mobile UX pass on the Sales quotation/order screen, including a fix for combo products being
  effectively unconfigurable on mobile: the product catalog search panel and the order line actions
  (combo configurator, manual discount, shipping, loyalty coupon/reward) were designed desktop-first and
  didn't adapt well to small screens.

  Current behavior before PR:
  - Configuring a combo product was not possible at all from mobile: tapping a combo line opened the
  generic line form (product_id as a plain many2one_barcode field) instead of the combo configurator, so
  there was no way to pick combo items on a small screen.
  - The product catalog search panel used the generic responsive web.SearchPanel layout on mobile, which
  is cramped and hard to use on a small screen.
  - Order lines (mobile kanban) exposed raw inline controls ("Add Line", "Add Section", "Add Note",
  "Catalog") directly in the list footer.
  - Shipping / discount / coupon / reward were desktop-sized buttons with no mobile-specific layout,
  competing for space on small screens.

  Desired behavior after PR is merged:
  - Tapping a combo line on mobile now opens the combo configurator dialog to pick items, same as the
  desktop flow.
  - The product catalog search panel opens as a dedicated mobile drawer (slide-in panel with backdrop)
  instead of the generic responsive layout.
  - Order lines mobile kanban drops the inline create controls in favor of a single "Add" button that
  opens the product catalog.
  - Combo selection and manual discount are exposed as compact dropdown widgets (combo_menu /
  discount_menu) on mobile.
  - Shipping / discount / coupon / reward actions are split into a compact mobile variant and the
  existing desktop variant (d-none d-md-block).
  - Combo lines can be deleted directly from the combo configurator dialog on mobile.


task-5270010

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

This PR adds various UI improvements in different modules.

# Base
- 3 filters to group users by fields: company, language and role in company (user/admin)
- 2 new optional fields in the user list view: date of creation and default company
- possibility to access an user form by clicking on the pending invitation badge
- button to hide/show password in identity check form and password change form
- improves the clarity of the password asked during identity check by stating that it requires the admin password

# Base_setup
- Removes the icon next to the number of active users in general settings

# Auth_signup
- Adds a filter grouping users by the state of the invitation sent
- Changed the color of the "Invited" status from blue to grey, indicating the user is still a draft
- Changed the message in the notification received when sending a mail invitation to a user to make it more clear

# Auth_totp
- Improves the readability of 2FA forms issued from mail 2FA and authenticator 2FA in order to reduce
the mental load and make the form clearer and more explicit while also removing the "cancel" button in the forms.
- Modifies the mail template containing the code by moving the expiration delay directly under the code.
- Updates the tests by removing the verification of a deleted label and modify various string values

# Web
- Hides logo in webclient forms for companies having no logo or using the default logo

# Hr
- Makes the error message clearer when trying to create an employee for a company they don't belong to by indicating what to do to fix the issue.
- Adds a redirection towards a user's newly created employee form when clicking on the "Create employee" button in the user form, allowing to check if the information are correct

# Crm
- Add the possibility to search on opportunity in pipeline and leads analysis views

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

As part of a partnership with a social secretariat (*chut chut pas de marques*),
some Odoo instances that use the Belgian payroll will submit their dimona
declarations via the batch channel.

This causes all sorts of problems with the current flow, which uses the
ONSS web service and assumes everything happens right away.

This PR aims to introduce several hooks/entry points for an async
channel to be able to be 'added' on top of the standard belgian payroll
without the need to massively rewrite parts of it.

It also fixes 2 bugs discovered whilst working on this batch channel
flow.

Note that without specific code overrides (for which this PR introduces
helper methods), the behaviour is nigh identical to what it was before:
the REST flow still works as it did before.

The only behavourial change introduced by design in commit
`l10n_be_hr_payroll: don't abort a save over incomplete Dimona data`:
instead of outright preventing a user (or a piece of code) from creating
an employee with missing data (with regards to the dimona declaration),
it saves it with a note in the chatter + the 'Dimona Issues' flag.

modules: `hr_expense, sale_expense, project_sale_expense`

Removing `accounting` functional flow from the `expense` module.
- The `hr_expense` user used to `post` expenses, now they can only `approve` them.
- Approving an expense will create `draft` moves.
- `accountant` users will post the moves instead.
   - An `employee-paid` expense linked to a `draft` move will be considered as `approved`
   - When the move gets `posted`, the expense will be set to `posted` too.
   - A `company-paid` expense linked to a move, it will be considered `paid`, regardless of the `move.state`
- Removing the `hr.expense.post.wizard` for `employee-paid` expenses, the accounting date default is now `today`
    - the `sale_expense` option to import attachments is now on the `sale.order` form view, as a button that opens a wizard to select what attachments the user wants to import from linked expenses
    - `journal_id` on `hr.expense` is now computed, as we lost information for `employee-paid` expenses by removing the wizard
- Add a filter in the `account.move` list view to display entries linked to expense
- Add a link from journal dashboard to all the draft moves linked to expenses

Enterprise PR: https://github.com/odoo/enterprise/pull/126246
Upgrade PR: https://github.com/odoo/upgrade/pull/10950

Task [link](https://www.odoo.com/odoo/project.task/6327097)
task-6327097

Steps to reproduce:
- German PoS with Fiskaly TSS configured
- Set a customer that is an address contact (type invoice/delivery/other) on an order; such a contact has no name of its own, it is displayed with its parent's
- Close the session

Issue:
Closing crashes with "TypeError: 'bool' object is not subscriptable" and the session cannot be closed at all.

Cause:
_get_dsfinvk_cash_point_closing_data builds the DSFinV-K buyer block from partner.name, which is only guarded by "if partner := o.partner_id". res.partner.name is not required: the res_partner_check_name constraint only enforces it for type='contact', so an address contact stores NULL there and partner.name reads as False, which cannot be sliced.

Fix:
Fall back on complete_name - what the UI displays for those contacts, "Parent Company, Delivery" - and on a literal when even that is empty, since the buyer name is mandatory in the export. Reading name first leaves the exported value untouched for every partner that has one.

opw-6518336

Forward-Port-Of: odoo/enterprise#131212
Forward-Port-Of: odoo/enterprise#129709

## Context:
When all references to stock functionality were extracted from point_of_sale in this PR: #241368, we decoupled the query ordering logic from the rest of our product.template data-fetching code: https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/point_of_sale/models/product_template.py#L190

This allowed us to completely override (not extend) the ordering of the loaded products in our new pos_stock module:
https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/pos_stock/models/product_template.py#L42-L65

Notice the difference in point_of_sale:
https://github.com/odoo/odoo/blob/1170bafbd7d9461d13ba1d6020d6f8487660763c/addons/point_of_sale/models/product_template.py#L403-L416

This was causing problems with our existing test for this feature in point_of_sale because we were explicitly examining the ordering of the products; obviously this ordering would be different when pos_stock is installed alongside point_of_sale.

Thus, we must decouple our original test for this feature so that ordering can be examined independently in each module's tests.

## Now:
We have one test in point_of_sale that just makes sure our limited products loading feature actually caps the number of products loaded. This test will work correctly whether or not pos_stock is installed.

In addition, we have one more test in point_of_sale and pos_stock that explicitly examines the ordering of the products in these limiting conditions when both modules are installed. The point_of_sale test will be skipped when pos_stock is installed because the latter module defines conflicting ordering.

runbot-243064

Forward-Port-Of: odoo/odoo#283621

### Issue before this commit:
Generating a SEPA Credit Transfer XML for certain European banks (e.g., Austrian and German banks) fails because the generated XML contains an unexpected `<CtrySubDvsn>` tag inside the `<PstlAdr>` node, leading to the rejection of the batch payment file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_at
2. Go to settings and activate SEPA Credit Transfer / ISO20022
3. Go to Journals > Bank > set an account number
4. Create an austrian contact (ex. FK Austria Wien AG) and set in the invoicing tab a bank (ex. AT526000071856851733) and set it trusted
5. Go to Bills, create a new one with the contact created and confirm it
6. Then click 'PAY' and select SEPA Credit Transfer
7. Go to Vendors > Batch Payments
8. Create a new one with:
	1. Bank as bank
	2. SEPA Credit Transfer as Payment Method
	3. Add the bill just created
9. Validate and download the XML
10. See that a wrong tag <CtrySubDvsn> is added. This makes some banks refuse it

### Cause of the issue:
External commit 30b023d394a5e4de64873188aa1d5961fecccb10 introduced the `<CtrySubDvsn>` tag to support US and CA requirements. However, the change was incorrectly applied to the common `account_iso20022` file, making it leak into standard European SEPA exports where the tag is not compliant with certain strict banking validation rules.

### Reason to introduce the fix:
Revert the generic addition of the `<CtrySubDvsn>` tag in the common ISO20022 XML generation and restrict it only to the specific localizations (US/CA) that require it. This brings the `<PstlAdr>` node back to compliance, allowing Austrian, German, and other European banks to successfully process the files.

opw-6523035

Forward-Port-Of: odoo/enterprise#131156
Forward-Port-Of: odoo/enterprise#131090

Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera` to their accept attribute: a mimetype which is not an image is enough to get the generic chooser, and its camera, back.

https://issues.chromium.org/issues/40937303

That invalid mimetype was appended for everyone, while only the browsers based on Chromium on Android need it:

- the issue is an Android one, the desktop file dialogs are not concerned
- the native app builds its own file chooser out of the accept attribute, and the invalid mimetype makes it offer the document picker on a field which only accepts images
- Firefox and Safari are not based on Chromium and are not affected

The workaround is now limited to the browsers needing it, and the expression moved from the template to a getter, since it is no longer a simple concatenation.

Code made by Claude
Supervised by RFR

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

Forward-Port-Of: odoo/odoo#287923
Forward-Port-Of: odoo/odoo#285643

Steps to reproduce:
-------------------------------------
1. Open the chatter of any record
2. Open the full composer for the Log Note
3. Add some text and paste some images > Post the log note
4. Click on the Edit option
5. Save the message without editing anything

Observation:
-------------------------------------
You will notice that the (edited) label appears even though the message wasn't edited at all, only the edit mode was made active.

Issue:
-------------------------------------
When a message is posted via the mail composer, the email conversion pipeline injects MSO conditional comments like
`<!--<![endif]-->` and `<!--[if mso]>...<![endif]-->` into the HTML body. These comments are added by the `_hideForOutlook` and `createMso` https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1978-L1988

https://github.com/odoo/odoo/blob/083e091eaa7d983f6c826c02b0d0652a821227fb/addons/mail/static/src/views/web/fields/html_mail_field/convert_inline.js#L1699-L1707

functions to ensure Outlook compatibility, they wrap responsive elements so that Outlook receives simplified table-based fallbacks while modern clients see the original layout. The stored message body on the server retains these comments. When a user clicks "Edit" on such a message, the body is loaded into the OdooEditor. The browser's DOM parser treats `<!--<![endif]-->` as standard HTML comment nodes, which are not preserved in `innerHTML` serialization. So the editor returns the body without these comments, even if the user made no changes. The `edit()` method in then compares `updatedBodyEl.innerHTML` (from editor, no comments) against `messageBodyEl.innerHTML` (from server, has comments), finds a difference, and sends a update to the backend, which stamps the message with the (edited) label.

Solution:
-------------------------------------
Before comparing innerHTML, strip all HTML comment nodes from both the original and updated body elements. This is done on throwaway DOM elements created solely for comparison. The actual body sent to the server (`body` parameter) is never modified.

Note:
-------------------------------------
An alternative approach would be to strip comments at the string level using a regex (`html.replace(/<!--[\s\S]*?-->/g, '')`) before creating the DOM elements. This is valid since HTML comment syntax `(<!--...-->)` is strictly defined and no nesting is allowed, so the regex is reliable.

This commit also preserve images while trimming empty message boundaries. Newer test covers this issue.

opw-6328529

Forward-Port-Of: odoo/odoo#287502
Forward-Port-Of: odoo/odoo#274927

It is a functional request to add him to the groups even if he is not
involved by a functional access.

[FIX] base: prevent group desync in user onchange

When editing a user in the web client, the onchange mechanism creates a
virtual record using `new(values, origin=record)` to build the baseline
snapshot used for field diff tracking.

In `res.users.new()`, logic automatically adjusts `group_ids` (adding or
removing `base.group_multi_company` depending on the number of companies
on the user) as a side effect. When `new()` was called with an `origin`,
this side effect corrupted the reference snapshot. Consequently, the
onchange return value failed to detect or report the real delta to the
web client, leaving the UI in an incorrect or desynchronized state (e.g.
`role` radio buttons or access right checkboxes out of sync with actual
groups).

Fix this by skipping the automatic group adjustment in `new()` when
`origin` is present, keeping the reference snapshot clean.

Add tour tests to ensure `role` and group checkboxes stay synchronized
across saves and page reloads in the web client.

Issue:
The calendar multi-create popover retains its form values so they can be reused when adding entries to another selection. In a variable working schedule, this retained state incorrectly restricted Time Type to the first allowed value after mass creating entries and deleting one occurrence.

Refreshing the page restored all Time Type options because the form was then rebuilt from the complete backend value of `allowed_work_entry_type_ids`.

Steps to reproduce:
- Open a working schedule and switch it from Fixed to Variable.
- Select multiple days and mass add working-time entries.
- Select one of the created days and delete its entry.
- Select that day again and open the Add popover.
- Open Time Type and observe that only the first allowed type is available.
- Refresh the page and observe that all allowed types are available again.

Cause:
`work_entry_type_id` is filtered by the computed `allowed_work_entry_type_ids` relation. The relational model keeps every relation ID in `StaticList.currentIds`, but only materializes the loaded page in `StaticList.records`. Since this invisible domain dependency has no related display fields, its loaded page is limited to one record.

When the multi-create popover was submitted or closed, 

https://github.com/odoo-dev/odoo/blob/23266b3a3bf0856dc147e3780e5ac54469bbcc53/addons/web/static/src/views/view_components/multi_selection_buttons.js#L169-L180

serialized x2many values from `StaticList.records`. This reduced `allowed_work_entry_type_ids` to its first loaded ID in the retained `multiCreateValues`. Reopening the popover reused that incomplete relation, so the Time Type domain correctly evaluated against only one ID.

Solution:
Serialize x2many values from `StaticList.currentIds` so every related ID is preserved. For loaded records, merge the cached record data to retain edited or display values, for unloaded records, retain an ID-only value.

This keeps the complete domain dependency across calendar multi-create popovers without changing the backend Time Type computation.

opw-6398706

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

Forward-Port-Of: odoo/odoo#280391

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

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

Forward-Port-Of: odoo/odoo#287019
Forward-Port-Of: odoo/odoo#258604

purpose:
1- We should have a consistent way to compute `_gantt_unavailability` of employees in time off and attendance. Currently, some cases have inconsistent behavior such as out of contract days, flexible and fully flexibe employees. 2- In time off calendar view, if the employee does not have a contract at all, the current working schedule will appear in the calendar and it will not be greyed out. This is inconsistent with the behavior of the attendance application.

Fix:
1:
- implemented `_get_employee_unavailable_intervals` in employee model to be used in both time off and attendance.
    - more optimized than the old implementation in time off as it calls `_work_intervals_batch` once per calendar instead of calling it for each contract in `_unavailable_intervals_batch`
    - greys out "out of contract" periods
    - for flexible and fully flexible employees, the whole period is considered available except leave periods
    - for duration based calendars, morning and afternoon map to 12 hours of availability and full day maps to 24 hours of availability
- made `_get_calendar_periods` use version date start instead of contract date start and corrected a bug in tz conversion 2:
- made `_get_unusual_days` return True for all the days outside of contracts for the employee instead of not returning anything for them or getting values from the working schedule of the employee (means that they will be greyed out in the callendar view) and added a test for it

task-id: 5473055

Forward-Port-Of: odoo/enterprise#130714
Forward-Port-Of: odoo/enterprise#113498

Bulk sending is queued: the batch wizard stamps sending_data on the moves and
lets the send cron do the work.

Before this commit:
Reset to Draft stayed available while the moves were being sent, so the user
could reset an invoice mid-submission. The invoice then ended up draft with an
accepted submission and could be sent to ZATCA a second time, which ZATCA
treats as a taxpayer compliance issue.

After this commit:
The records are locked on both sides, the way l10n_jo_edi does. Reading the
state instead would not help, as a transaction only sees the snapshot taken
when it started, in which the move is still posted.
1. When submitting, the moves that cannot be locked are skipped, as another
   transaction is already working on them.
2. When resetting to draft, the reset is refused if the records cannot be
   locked, otherwise it applies once the submission it races with committed.

Reset to Draft stays available for invoices accepted in Sandbox and Simulation,
as deleting or resubmitting test invoices is the point of those modes.
Production remains covered by the l10n_sa_edi_is_production check.

Steps to reproduce:
1. Install l10n_sa_edi and onboard a sales journal in Sandbox mode.
2. Create and post two invoices.
3. Select them, Action > Send & Print.
4. Select them again, Action > Reset to Draft.

task-6267293

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

Forward-Port-Of: odoo/odoo#284107

Issue:
Colombian child contacts linked to a NIT company are displayed with their standalone name instead of "Company, Contact". Searching Contacts by the company name consequently returns the company but not its child contacts.

Steps to reproduce:
- Create a Colombian company with NIT
- Add a child contact or address to that company
- Filter Contacts by the company name
- Observe that the child is displayed separately and is not returned

Cause:
The Colombian `is_company` computation classifies every partner with a Colombian NIT and qualifying obligations as a company: https://github.com/odoo/enterprise/blob/911686a31d5d3c1539d0dff7d16edf1ce9b101ca/l10n_co_edi/models/res_partner.py#L43-L53

Those fiscal values are commercial fields and are propagated to child contacts. Without checking that the partner is its own commercial entity, children are therefore classified as companies, preventing the standard display name logic from prefixing their parent name.

Solution:
We need to restrict the Colombian company classification to partners that are their own commercial partner. This preserves the NIT and obligation rules for actual companies while keeping their inherited child records as contacts, restoring both the combined display name and parent name search behavior.

opw-6470958

Forward-Port-Of: odoo/enterprise#130373
Forward-Port-Of: odoo/enterprise#128986

As Odoo grows, we're always looking for ways to make our apps even more accessible and user-friendly. Over time, we've noticed that our current Marketing Automation app requires a bit of a technical background to get the most out of it. While the engine under the hood is super powerful, the sheer number of options can feel a bit overwhelming for everyday users who just want to get a campaign running quickly.

To bridge this gap and open up the app to everyone, we're giving it a fresh, modern makeover! The goal of this task is to shift toward a fully visual experience. This PR introduces a brand-new custom graph view that makes campaign building much more intuitive.

Instead of managing complex configurations through standard forms, users can now see their entire marketing flow mapped out clearly. Building a campaign becomes super straightforward: you can add, remove nodes on the fly to design your workflow visually.

Instead of throwing all options into a single, heavy form, we've split the configuration into specific, easy-to-understand node types (like Delay, Filter, and Interaction). This keeps the interface clean, clutter-free, and way easier to use.

ENT: https://github.com/odoo/odoo/pull/258112

Task-3866422