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