When a signing template has a custom redirect link, signers now see only that redirect option after completing the document. This helps businesses guide users to the intended next step and avoids confusion from extra default choices.

Purpose
When you customize your "Redirect link" for a Template:
- Current behavior: you get default actions (Return to templates and Download document) + the new redirect link
-Expected behavior: having only the redirect link

Specifications 
Customized redirect link is available:
 - In "properties" of templates
 - In debug mode and
 - For templates with "share" option (meaning, with only one role)
Wizzard appears when document is fully signed

LINKS
PR: #9692
TaskID: 2230042

The Timesheet and Planning Analysis report now shows planned hours correctly and presents clearer reporting information. Users also get a better pivot view with effective hours, planned hours, and the difference, without being limited by a default current-month filter.

Purpose
=======

Small improvements in Timesheet and Planning Analysis

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

In Timesheet and Planning Analysis report:
- fix missing planned hours
- rename the title
- remove default filter set on the current month

Demo field service projects now use the intended default worksheet, making sample data more consistent for users evaluating the field service reporting flow. This helps demonstrations and trials better reflect the expected setup without requiring manual adjustment.

TaskID: 2254690

Shift creation in Planning no longer automatically fills a role when starting from an open shift line. Employee or role values are now only prefilled when they are explicitly provided by the web client, reducing unwanted assignments and improving scheduling accuracy.

* The role should not be automatically filled in when created from a
 open shift line.
 * Only prefill employee or role when they have a default value coming
 from the web client.

TaskID: 2247353

This change rolls back the recently introduced IoT pairing module because it caused upgrade issues across saas-13.4 branches. Reverting it helps keep deployments stable while upgrade scripts are corrected before the feature is reintroduced.

A skipci was made in order to merge a new module `iot_pairing` in saas-13.4.
Unfortunately after the module reached master, beb3851 was introduced before new saas-13.4 database
were generated, allowing to merge the change in master but introducing the failure in saas-13.4
for all other branches.
The failure should appear in master after saas-13.4 nightly.
This reverts commit beb3851 waiting for a fix nof upgrade scripts.

IoT Boxes now connect through a short-lived manual pairing code instead of direct browser communication, avoiding issues caused by browsers blocking mixed content. This keeps customers able to register new IoT Boxes securely and reliably as browser security rules tighten.

In Chrome 84, mixed content will be completely blocked for security
reasons ([see blog](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html))
Other browsers will probably follow in the next months.

As IoT Boxes don't have a valid certificate before connecting to a DB,
we used mixed passive content to communicate with the boxes.
This won't be possible anymore, and we have no possible way to
communicate directly from the browser to the box.

- When an IoT Box boots without registered DB, a unique code will be
 created with a validity of 5 minutes.
- This code will be shown on the customer display and printed on the
 status ticket.
- The box will call a route on odoo.com and a record will be created
 in odoo.com with the unique code.
- The user will have to enter the code manually in his DB to connect
 to the IoT Box, the DB will then contact odoo.com to search for a
 record containing the unique code. If it's found, the
 `openerp.enterprise.database` will be added to the record.
- The box will then query odoo.com at regular intervals (10 seconds)
 to check if a DB is linked to the code.

Taskid: 2246535
X-original-commit: 05de66e6ea815e32b463f1e49e974d30fcf05ac4

The separate IoT Box pairing component has been removed because its setup flow is now part of the main IoT module. This simplifies the product structure while keeping the IoT Box connection wizard available in the standard IoT experience.

The iot_pairing module was added in stable versions (#371ef55)
because we needed to modify the IoT Box connection wizard.
We can now remove it in master and integrate it with the
IoT module.

TaskID: 2246535

…ezones Purpose ======= If a user in timezone X creates a planning slot for employee in timezone Y (from the gantt view): the default hours are midnight to midnight (in the user's timezone). Which are then adjusted to the employee's calendar. However, the period midnight to midnight spans across two days in the employee's timezone. This leads to weird situations when searching for the closest attendance in the calendar. E.g. User in timezone "Asia/Colombo" (+05:30) and employee in

…ezones

Purpose
=======
If a user in timezone X creates a planning slot for employee in timezone Y
(from the gantt view): the default hours are midnight to midnight (in the
user's timezone). Which are then adjusted to the employee's calendar.
However, the period midnight to midnight spans across two days in the
employee's timezone. This leads to weird situations when searching for
the closest attendance in the calendar.

E.g.
User in timezone "Asia/Colombo" (+05:30) and employee in timezone
"Europe/Brussels" (+02:00)
with a standard 40h/week calendar (from 8am to 12 and 1pm to 5pm everyday)
Create a slot the 2nd June.
Default hours are 00:00 to 23:59 (in "Asia/Colombo").
Which is 1st June 18:30 to 2nd June 18:29 (in "UTC")
Trying to find the closest attendances in the employee's calendar would
give 1st June 1pm to 2nd June 5pm (in "UTC").
Which displays 1st June 4:30pm to 2nd June 10:30pm (in "Asia/Colombo") to the
user who might not understand where those times are coming from.

Specification
=============
Do not try to use the employee's calendar if the user and employee have
different timezones.

Forward-Port-Of: odoo/enterprise#10886

When the user attempts to upload or replace a file in Documents from an iOS device, the native file chooser opens but selecting a file doesn't trigger the upload. The reason behind this behaviour is that, on iOS, in order to have a `onchange` event be triggered from a `<input type="file">` element, this input have to be attached to the DOM. This commit fixes it by actually attaching the hidden input to the DOM and also prevents it from cluttering too much the DOM when the user cancel

When the user attempts to upload or replace a file in Documents from an
iOS device, the native file chooser opens but selecting a file doesn't
trigger the upload.

The reason behind this behaviour is that, on iOS, in order to have a
`onchange` event be triggered from a `<input type="file">` element, this
input have to be attached to the DOM.

This commit fixes it by actually attaching the hidden input to the DOM
and also prevents it from cluttering too much the DOM when the user
cancels its action (cf. cancel doesn't trigger any event).

opw-2260895

Forward-Port-Of: odoo/enterprise#11415
Forward-Port-Of: odoo/enterprise#11400

task-2280147 Forward-Port-Of: odoo/enterprise#11398

task-2280147

Forward-Port-Of: odoo/enterprise#11398

ThreadViewer now takes a prop to allow or not the scrolling to the relevant message When the chatter is on the side it is allowed to adjust its scrolling task-2238141 Forward-Port-Of: odoo/enterprise#11213

ThreadViewer now takes a prop to allow or not the scrolling to the relevant message
When the chatter is on the side it is allowed to adjust its scrolling

task-2238141

Forward-Port-Of: odoo/enterprise#11213

In Chrome 84, mixed content will be completely blocked for security reasons ([see blog](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html)) Other browsers will probably follow in the next months. As IoT Boxes don't have a valid certificate before connecting to a DB, we used mixed passive content to communicate with the boxes. This won't be possible anymore, and we have no possible way to communicate directly from the browser to the box. - When an IoT Box boots

In Chrome 84, mixed content will be completely blocked for security
reasons ([see blog](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html))
Other browsers will probably follow in the next months.

As IoT Boxes don't have a valid certificate before connecting to a DB,
we used mixed passive content to communicate with the boxes.
This won't be possible anymore, and we have no possible way to
communicate directly from the browser to the box.

- When an IoT Box boots without registered DB, a unique code will be
 created with a validity of 5 minutes.
- This code will be shown on the customer display and printed on the
 status ticket.
- The box will call a route on odoo.com and a record will be created
 in odoo.com with the unique code.
- The user will have to enter the code manually in his DB to connect
 to the IoT Box, the DB will then contact odoo.com to search for a
 record containing the unique code. If it's found, the
 `openerp.enterprise.database` will be added to the record.
- The box will then query odoo.com at regular intervals (10 seconds)
 to check if a DB is linked to the code.

TaskID: 2246535

Forward-Port-Of: odoo/enterprise#11375
Forward-Port-Of: odoo/enterprise#10539

In the balance sheet some accounts (550, 551, 554, 5525, 5523, 5524) must be counted in the passive if they balance is negative and must be counted in the active if the balance is positive. opw-2252420 Forward-Port-Of: odoo/enterprise#11411 Forward-Port-Of: odoo/enterprise#11397

In the balance sheet some accounts (550, 551, 554, 5525, 5523, 5524)
must be counted in the passive if they balance is negative and must be
counted in the active if the balance is positive.

opw-2252420

Forward-Port-Of: odoo/enterprise#11411
Forward-Port-Of: odoo/enterprise#11397

Steps to reproduce the bug: - Let's consider a subscription template ST - Let's consider two subscription products P1 and P2 linked to ST - Go to form view of P2 and untick Subscription Product - Create a SO with P1 and P2 and validate it Bug: A subscription was created with P1 and P2 instead of just P1 opw:2279374 Forward-Port-Of: odoo/enterprise#11390

Steps to reproduce the bug:

- Let's consider a subscription template ST
- Let's consider two subscription products P1 and P2 linked to ST
- Go to form view of P2 and untick Subscription Product
- Create a SO with P1 and P2 and validate it

Bug:

A subscription was created with P1 and P2 instead of just P1

opw:2279374

Forward-Port-Of: odoo/enterprise#11390

...in case of the sale.subscription.template is set to Manually Create a subscription having the create invoice set to Manually shouldn't create an invoice when the sale_subscription is in state running unless it has been specifically asked for (using the create invoice button). As the domain wasn't filtering on this parameter, the 'manually' was managed as the 'draft_invoice'. completing opw-1935178 completing commit-entreprise/599fe85 opw-2278589 Forward-Port-Of: odoo/enterpr

...in case of the sale.subscription.template is set to Manually

Create a subscription having the create invoice set to Manually
shouldn't create an invoice when the sale_subscription is in
state running unless it has been specifically asked for
(using the create invoice button).

As the domain wasn't filtering on this parameter, the 'manually'
was managed as the 'draft_invoice'.

completing opw-1935178
completing commit-entreprise/599fe85

opw-2278589

Forward-Port-Of: odoo/enterprise#11281
Forward-Port-Of: odoo/enterprise#11269