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

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

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.

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

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

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

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