### Context
The previous signer status header in the sign app relied on static QWeb injected from the backend and legacy DOM manipulation (jQuery/Vanilla JS) to handle state changes like "Resend" buttons. Additionally, the horizontal layout consumed too much screen space for documents with multiple signers, and users lacked quick visual context of the document's template tags.

### Summary of Changes
This PR completely modernizes the Sign Request Control Panel header, moving it to a pure OWL architecture while vastly improving the UI/UX.

1. Architectural Refactoring (Legacy JS to OWL)

Extracted the signer status wrapper into a modern, reusable OWL public component (SignerStatusBadge) that works flawlessly in both the backend and the portal.

Ripped out fragile querySelector DOM manipulation for the "Resend" buttons. Button state (e.g., swapping a paper-plane icon for a success checkmark upon clicking) is now fully managed via reactive OWL state and clean RPC calls.

2. UI/UX Redesign

Redesigned the signer list into a compact, native Odoo <Dropdown> when multiple signers are present, saving valuable horizontal space.

Replaced bulky text buttons with clean, semantic Bootstrap/FontAwesome icons (check/clock/cross for status, paper-plane for actions) for a more modern SaaS feel.

3. Added Template Context

Reused the existing SignTemplateHeaderTags component to display the original template's tags directly in the request control panel (in read-only mode). It gracefully hides itself if no tags or template exist.

Task: 6109365

Purpose
=======

This PR addresses many improvements in the social app, the two main
ones being allowing to link your personal LinkedIn account and to post
Facebook and Instagram "Stories".

We also made a lot of UX tweaks along the way to make the social app
easier to use, with a bit of much needed polish as the app has not been
worked on a lot since it was introduced (about 7 years before this PR).

Specifications
===========

Allow the users to add their personal LinkedIn account in Social (and 
not only the page for which they are admin), and to post on them.

During the authentication process of Social, if something went wrong
we need to manually go back or enter the Odoo database URL to retry.
It can be very frustrating, and so now we open the authentication URL
in a new window, and when the process is done we close the window
and refresh the view.

Show a loading page while doing the token exchange process (which can take some time depending on the number of pages).

Allow removing the accounts from the "Connect Account" modal.

Show the icons of the selected medias in the calendar view.

Improve the way we schedule posts.

Allow the users to comment their own posts right after posting.

Allow posting stories on Facebook and Instagram.

Allow sorting the image when posting on a social media.

Use AI to write social post. Show the chars count for all medias while typing the message.

Improve the computation of the tweet length (URL must count for 23 chars and emoji for 2).

In the post form view, show the media icon instead of the media name
when selecting the accounts.

Do some refactoring to unify the name for the social post message field.

Schedule the social post with a modal, like it's done in mass-mailing.

(see each individual commits for more details)

Task-5491124

- Step to reproduce: open the salary configurator for a belgian employee with only a car to order linked to its version. Car info and simulation button are not appearing and the page reactivity is broken
- Cause:
    - Broken page reactivity is due to a promise that never resolve in willStart super call because of race condition caused by overlapping calls to a debounced function
    - Car model description is computed and displayed only when a new value is passed
    - Simulation button is rendered only on select value change
- Solution:
    - Execute `updateGross()` and `setUpBenefits()` sequentially in parent willStart to prevent overlapping salary recomputations during startup
    - Implementing a condition that handle the case of the new car value being already set in the description computation function
    - Triggering the new car change function in willStart so that the simulation button is rendered on page load

Task: 6241194

Forward-Port-Of: odoo/enterprise#120614
Forward-Port-Of: odoo/enterprise#118647

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#120931
Forward-Port-Of: odoo/enterprise#120601

**Problem:**
Two linked errors occur in the Phone (VoIP) softphone when a call is made to or received from a number that is not linked to any contact.

**Steps to reproduce:**
1. Receive or make a call from the softphone using a phone number that is not linked to any existing contact.
2. Open the call's actions and click "Create" > "Task". -> A client error appears and the task is not created.
3. On a voip.call form whose Contact has been removed, click the "Tasks" smart button. -> A server error is raised.

**Current behavior:**
Step 2 raises "Cannot read properties of undefined (reading 'id')" and step 3 raises "ValueError: not enough values to unpack (expected 1, got 0)".

**Expected behavior:**
Creating a task from a contactless call should open the task form without a default contact, and the Tasks smart button should not be reachable when the call has no contact.

**Cause of the issue:**
Both code paths assume a call always has a linked partner. In `action_list_patch.js`, `getCreateTaskAction` only checks `shouldShowTaskButton` in its predicate but reads `this.contact.id` in its `onClick`; for a contactless call `this.contact` is undefined. In `voip_call.py`, `action_view_tasks` delegates to
`self.partner_id.action_view_tasks()`, whose `ensure_one()` fails on the empty partner recordset. Unlike the softphone "view tasks" action, which is gated by `this.contact?.task_count`, the form stat button had no visibility guard.

**Fix:**
The create-task action now mirrors the existing contact and lead actions, which already build their context conditionally on `this.contact`, so a contactless call simply opens the task form with no default partner. The Tasks stat button is hidden when there are no tasks, matching the softphone predicate and ensuring the partner-less code path is never reached.

opw-6246641

Forward-Port-Of: odoo/enterprise#119412

Several related fixes around the AvaTax connection settings:

- Surface an unconnected "Avalara Included" setup instead of silently using Direct credentials. Filling Direct credentials, switching to Included, then not completing the connection (link/migrate/create) left the company looking configured through those leftover credentials: the user believed they were on Included while a request either silently used Direct or crashed on the unset IAP proxy user (ensure_one). Direct credentials now only count in Direct mode, so the not-connected state raises the usual RedirectWarning pointing to the configuration.

- Group nexus locations by country in the connection test result. The list dumped every nexus row flat, so countries appeared alongside their own regions and each jurisdiction repeated once per tax type (e.g. "California" dozens of times). Group by country, drop the country-wide rows, dedupe and sort, with a short summary line.

- Make the "Help me choose" documentation link version-aware via the documentation_link widget instead of the /latest/ alias, which redirects to the latest major release (19.0) where the AvaTax docs don't exist.

task-6295272

Forward-Port-Of: odoo/enterprise#120761

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

When clicking the create payment report button on a payslip for a Swiss company,
a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed.

Steps to reproduce the error:
- Install ``l10n_ch_hr_payroll`` module
- Switch to CH Company
- Create an Employee and running contract for it
- Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report

Traceback:
```py
ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch'
```

https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13
Here, ``iso20022_ch`` is passed as ``export_format``,
However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1].
When that module is not installed, the selection value does not exist, leading to the above error.

[1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11

sentry-7391832811

Forward-Port-Of: odoo/enterprise#120825
Forward-Port-Of: odoo/enterprise#113277

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

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#120683
Forward-Port-Of: odoo/enterprise#118813

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

How to reproduce it:
- Install l10n_mx_reports and select Innovacion Company
- Go to accounting app > reporting and Open the General Ledger report
- Trigger the "XML Polizas (SAT)" export, fill in the wizard (export type and order/process number) and click Export
- A traceback is raised instead of downloading the file: TypeError: ... report_data: use BinaryValue instead of bytes

This error happens because export_xml writes the generated file to the report_data field as raw bytes. After the introduction of BinaryValue, no longer accepts bytes values (unless raw field) for Binary fields and now expects a BinaryValue, causing the traceback. The write was modified on refactoring PR, but not correctly and there wasn't a test targeting the url action part so it was not flagged.

This commit fixes the issue by wrapping the content in BinaryBytes (since is a BinaryValue) before assigning it to report_data and added tests covering the single and multiple period cases.

task-6297731

Forward-Port-Of: odoo/enterprise#120339