This commit introduces significant improvements to the User Interface (UI) and User Experience (UX) of the Sign application. The main focus is on making the Sign Template editing process more dynamic by:
- Introducing role assignments in the PDF view sidebar.
- Removing the top bar of the Sign Template Edition.
- Making the Signer Roles more customizable.

Below is a categorized summary of changes:

### Template List View:
- Reorganized fields in the template list view for better clarity.
- Updated template sharing options; sharing link behavior now follows conditions.
- Added a cog menu for template editing actions.
- Moved settings from the top bar to the new cog menu.
- Removed the top bar from the template edition interface.

### Documents List View:
- Reorganized the documents list view; removed the grouping sidebar.
- Fixed redirection issue in the template form when selecting "Cancel" in kanban view items.

### Templates Edition:
- Added OWL Sidebar to render sign items dynamically.
- Displayed a notification suggesting "Create Template" if a document is used at least three times.
- Moved inline document name editing to the sidebar.
- Transferred "Access Rights" option from the top bar to the cog menu.
- Relocated "Save as Template" option from the top bar to the cog menu.
- Enabled partner selection in the sidebar when signing an uploaded document.
- Enabled role selection in the sidebar for template and document editing.
- Allowed dynamic addition and removal of signers in the sidebar.
- Added fold/unfold functionality for signers in the sidebar.
- Made placeholders for sign items available without debug mode.
- Added field icons in the sign items.
- Removed employee names from sign items.
- Updated the selection field to a dropdown menu when signing.
- Introduced the new "Strikethrough" sign item.
- Added auto-rendering of sign Signatures during template edition.
- Improved selection field edition by adding multiple options then pressing Enter.
- Made the dragging of sign items more smooth, fixing the coordinates.

## Discussion about Sign Item Roles new usage (storage-wise):

After this PR, we made it easier to customer Sign Item Roles with the new sidebar. It was requested, in the task specification:
1. The removal of the Many2One fields for the signers in the sidebar;
2. The addition of a input field instead for editing the name of the signer;
3. A hamburguer menu with the options of editing the signer variables.

For achieving this, we had to create a new Sign Item Role record at each signer addition, for keeping the modifications and making the signer specifically linked to the currently template being edited. This way, a same Sign Item Role record can be edited without any problems on the current template it is linked without affecting other templates.

We estimated the amount of storage in PostgreSQL that will be necessary handling millions of Sign Item Role records below. Starting by the estimated size of a row of this respective class in the DB:

| Column            | Data Type   | Size (Bytes)          |
|------------------|------------|----------------------|
| `id`            | `bigint`    | 8                  |
| `sequence`      | `integer`   | 4                  |
| `create_uid`    | `integer`   | 4                  |
| `write_uid`     | `integer`   | 4                  |
| `auth_method`   | `text`      | 24 (20 chars + 4 overhead) |
| `name`          | `jsonb`     | 50 (average)       |
| `default`       | `boolean`   | 1                  |
| `change_authorized` | `boolean` | 1                  |
| `create_date`   | `timestamp` | 8                  |
| `write_date`    | `timestamp` | 8                  |
| **Total (without overhead)** |  | **112 bytes** |

Row Size Calculation: Total without padding = 112 bytes, Row overhead = 24 bytes, Aligned total (8-byte boundary) = 136 bytes. This way, following the calculated byte per row, including overheads, we got:

| Number of Rows | Total Size (Bytes) | Approximate Size (MB) |
|--------------|------------------|-------------------|
| 500,000      | 68,000,000       | ≈ 65 MB          |
| 1,000,000    | 136,000,000      | ≈ 130 MB         |
| 2,000,000    | 272,000,000      | ≈ 259 MB         |
| 4,000,000    | 544,000,000      | ≈ 519 MB         |

Thus, we can conclude that the current approach is not too heavy on a super large use case. If we made a similar behavior using computed fields (i.e. creating the record only when any of the fields is customized), we would have to change the entire behavior of the signers interaction in the sidebar and we would still need to create the record anyway.

Co-authored-by: Ahmad <alah@odoo.com>

task-4387560

Commit 1:
[FIX] documents: fix showing alias fields on details panel

Reproduce:
1. Go to a folder on the kanban view
2. If not configured, configure Email Servers, then redo 1.
3. Clear the domain of the alias
4. You are asked to configure servers again and you cannot set
any value for the alias.

Redirecting to the company settings is cumbersome and unlikely
useful. Erp managers should be able to quick create here as in
the company settings, as aliases are not company specific when
receiving.

Technically, removing `load=False` on `documents_unique_folder_id`
(added when there is a `search_panel_default_folder_id` without
`no_documents_unique_folder_id` in context) is necessary to load
the existing `alias_domain_id`'s `display_name`.

Commit 2:

[FIX] documents: fix reloading only search panel

It is not necessary to reload the model when we
want to reload the search panel.

Commit 3: 

[FIX] documents: fix validation error on saving container

These records' methods are sometimes called when there is no point
(and don't work), because the record is not part of the view.

This can be seen for example when adding alias tags.


Commit 4: 

Reproduce:
As an internal user not documents manager,
open the details panel on a company root folder
with access_internal="edit".
The fields are not rendered as readonly as they should.

Test data updated in documents_spreadsheet.

Task-4543501

Forward-Port-Of: odoo/enterprise#79019
Forward-Port-Of: odoo/enterprise#78375

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

Problem
---------
Currently, there is a discrepancy between the year filter in the reports and spreadsheet.

In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year.

For example, if the fiscal year starts on the 1st of April (01/04),
- in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024;
- in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025.

This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports.

Objective
---------
Make the report year filter behave like in spreadsheet.

Solution
---------
Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before.

opw-4493556

Forward-Port-Of: odoo/enterprise#78486

### Steps to reproduce:

- Create a bom for a product FP:
    - 1 x COMP (component)
    - operations: OP1:
        - instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button

#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')

### Cause of the issue:

Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.

### Fix:

We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).

### Note:

By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.

opw-4352828

Forward-Port-Of: odoo/enterprise#79017
Forward-Port-Of: odoo/enterprise#74795

### Issue:

Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records.

### Note:

This is easily reproducible by hand in localhost and should worsen if you have server delay. In addition, it makes it impossible to write a proper tour involving the catalog in the shopfloor.

### Steps to reproduce:

- Create a product with a bom and an operation op1
- Create and confirm an MO for 1 unit of that product
- Go to the shopfloor > on the operation > wheel > Add component
- Add a component to be consumed in that operation
- Close the catalog fast (using ESC for instance)

#### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor.

### Cause of the issue:

When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed.

### Fix:

We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved.

#### To be more precise:

The `ProductCatalogKanbanController` component contains a list of promises (initially empty): `catalogKanbanUpdates` aswell as an optional callback props `onCatalogUpdated`. This list is going to be populated each time that a `ProductCatalogKanbanRecord` make a quantity update (used stock moves on the mrp.production). To populate this array of promises a method is defined in the controller: `pushCatalogKanbanUpdate`. This method needs to be called by the `KanbanRecords` an hence is transported using xpath from the `ProductCatalogKanbanController` to the `ProductCatalogKanbanRecord` via the `ProductCatalogKanbanRenderer`. Once the controller is detroyed (and hence each kanban record that had to update a quantity started its call) if a callback was given to the props of the Kanban controller we wait for all the update promises to be resolved and we call that call back.

opw-4199156
---

To reproduce:
(Note that this needs to be donne before https://github.com/odoo/enterprise/commit/03fd8fa9ce59f3b052ba112612ee288cd44f045a ; you can easily replicate by indenting the add of the "Send" button one more level to the left, so that the button is always added, as it used to be)

1) Duplicate the Partner Ledger
2) Set the original Partner Ledger as the root report of the duplicate 3) Open the Partner Ledger, and select the duplicate in the variant selector

===> The "Send" button is displayed twice on top of the report.

This is due to the fact the custom handler is first called by the report itself (since the duplicate kept the same handler as the root Partner Ledger), then by the call to super() made in the _custom_options_initializer.

In the case of the Partner Ledger, we could have removed that super call (since it's a root report), but we prefer a more generic and cleaner fix that just makes sure we don't reinitialize the same custom options if we notice the handler is the same.

opw-4506968

In Chile localization it is possible to add a Related Document when
creating an Invoice Document. These documents info are then added to the Electronic
Invoice sent to the government.

Currently, when creating a Boleta Electronica and adding a Cross
Reference Document, the EDI system will not validate correctly the xml,
with error
`Error en Schema [0] LSX-00204: extra data at end of complex element`

This occurs because the system first creates a dte from a common xml schema, then
wrap it with the appropriate envelope.
However the schema of Boletas slighly differs[1], as it doesn't have the
field FchRef, so it gets rejected by SII

A solution is to modify the code of dte_subtemplate to make sure that FchRef
only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd,
and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd

[1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf

opw-4433202

Forward-Port-Of: odoo/enterprise#78177

### Steps to reproduce:

- Create a storable product FP tracked by SN with a BOM:
    - 1 Operation: - instruction: Register Production type (per product)
    - 1 x Comp (storable product in stock)
- Create and confirm an MO for one unit of FP.
- Go to the shopfoor app > open the instruction of your operation
- Type a non-existing serial number in the search bar > Create "new_sn"
> This opens a form view of the stock.lot model
- Save and close the new stock.lot
> Invalid operation: You are not allowed to create or edit a lot or serial number for the components with the operation type
> "Manufacturing". To change this, go on the operation type and tick the box "Create New Lots/Serial Numbers for
> Components"

#### Expected behavior:

The invalid operation should not be raised as the "required" option concerns only componenets and not final products.

### Cause of the issue:

Creating a stock lot will first launch a call of the `_check_create`: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/stock/models/stock_lot.py#L150-L153 However, since this check does not verifies that the product for which we create the lot is indeed related to a component of the MO it will raise the invalid operation even for final products: https://github.com/odoo/odoo/blob/c25d71f14fa168807f07cd88bed805d15db8add5/addons/mrp/models/stock_lot.py#L11-L17

### Issue 2:

Currently, the `quickCreate` ("Create *sn_name*") option of the lot field of te "register production" dialog calls a `name_create` that will set an error message in the logs as the product_id required field can not be provided neither in the vals or the context of the `name_create`.  You then fall back on the same form dialog than the "Create and edit".  The `quickCreate` option should therefore just be disabled.

Community: https://github.com/odoo/odoo/pull/193965

opw-4452747
---

Forward-Port-Of: odoo/enterprise#78966
Forward-Port-Of: odoo/enterprise#77265

Problem
---------
Currently, there is a discrepancy between the year filter in the reports and spreadsheet.

In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year.

For example, if the fiscal year starts on the 1st of April (01/04),
- in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024;
- in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025.

This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports.

Objective
---------
Make the report year filter behave like in spreadsheet.

Solution
---------
Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before.

opw-4493556

Forward-Port-Of: odoo/enterprise#78486