Commit 8f3e242e197b2f26982749 added an Etag to reduce the load on the network when loading a spreadsheet.

Now, this commit ensures the Etag is computed as fast as possible to also reduce the load on the server.

The Etag is based on the latest revision (field `current_revision_uuid`). When computing `current_revision_uuid`, we look at the lastest revisions. However, the current code only look at *active* revisions, and fallback on the snapshot.
The snapshot is a json file (potentially large) that needs be parsed. This is not fast.

To make it worse: spreadsheets are snapshotted as often as it can be, which means we almost always fall in the slow path when computing the Etag.

With this commit, we consider all revisions (active or not). We also load in memory only the latest instead of fetching multiple revisions for each spreadsheet (the work is done by postgres through `_read_group`)

On a spreadsheet with a snapshot of 9.8MB, server time
`"GET /spreadsheet/data/documents.document/17 HTTP/1.1" 304`

before: ~310ms
after:    ~5ms


Task-5431940

Forward-Port-Of: odoo/enterprise#102556

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#102575
Forward-Port-Of: odoo/enterprise#91378

Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.

Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion.

Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed:
"You can not delete a sent quotation or a confirmed sales order. You must first cancel it."

Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed:
"Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead."

Steps to reproduce on Runbot:
1. Install Appointments and ecommerce
2. For the dental care appointment, edit and enable "Up-front payment"
3. On the website, book an appointment for dental care and proceed to payment
4. Delete the sale order with the booking
5. Observe the incorrect error message being displayed

opw-5092349

Forward-Port-Of: odoo/enterprise#100371

Steps to reproduce:
1- Create new appraisal
2- Confirm appraisal
3- Edit employee and manager feedbacks
4- Set the final rating for the appraisal
5- Mark appraisal as done
6- Reopen appraisal

Issue:
The feedbacks of both the employee and manager are reset to the default template. They should be unchanged.

Cause:
Both the reopen and reset buttons used to call the the same action "action_back" which would set the state of the appraisal to "1_new", there is a compute that is triggered by the change in state which updates the appraisal's department_id which in turn triggers two other computes for the employee and manager feedbacks, those computes have a condition that if the state of the appraisal is '1_new', then the feedbacks should be reset to the templates.

Fix:
Make each button call its own action and make the reopen action set the state to '2_pending' instead of '1_new'. Furthermore make the reset action also reset the final rating for the appraisal.

Task-5411661

Forward-Port-Of: odoo/enterprise#102021

The system will crash with error when user tries to validate the signature.

**Steps to produce: -**
- Install `Sign, Employees, and Documents` apps with demo data.
- Go to Apps and `uninstall` the `hr_sign` module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.

**Error: -**
```
KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])
```

**Root cause: -**
- When `sign` route is called then at [1], then we try to search field `sign_request_ids` in `hr_employee`. but at [2], we can see the field `sign_request_ids` is defined in `hr_sign` module.
- And user removed the `hr_sign` module, so the field is no more exist in `hr_employee` model.

**Solution: -**
- Added new bridge module for `documents_hr` and `hr_sign`.

[1]
https://github.com/odoo/enterprise/blob/ec83cfc1ac4f0be9eacba4b7e9a41438050b8950/documents_hr/controllers/main.py#L20-L21

[2]
https://github.com/odoo/enterprise/blob/ec83cfc1ac4f0be9eacba4b7e9a41438050b8950/hr_sign/models/hr_employee.py#L9-L10

**sentry-6819182542**

*: stock_barcode

Before this commit:
=======================
When accessing a manufacturing order via Barcode in `dark mode`, the producing bar of the finished product is difficult to read due to poor colour contrast.

Steps to reproduce:
=======================
1. Install the `mrp` module.
2. Switch to dark mode.
3. Open any manufacturing order using Barcode.
4. Observe the producing bar for the finished product.

- The text on the producing bar is hard to read because the colour of text does not provide sufficient contrast.

- Additionally, for products tracked by `lot or serial number`,  when the same product is added multiple times, the barcode view groups these entries into a single grouped line, causing the same visibility issue in both MO and normal `picking/transfer` operations.

Cause of the Issue:
=======================
In dark mode, both the text and background colour of the producing bar are light, resulting in low colour contrast and making the text difficult to read. Additionally, the `text-muted` class applied to the `units of measure (UoM)` further reduces readability.

After this commit:
=======================
Updated the text colour of producing bar and background colour of grouped lines to use a darker shade for better visibility in dark mode. Also, removed the `text-muted` class used on `UOM` to improve redability.

TaskID-5117608

Forward-Port-Of: odoo/enterprise#96718

The thread action 'view-contact' is somewhat like 'livechat-info', in that this action redirects to relevant info to the whatsapp user and livechat-info is a panel with all info on the visitor and more.

The position of both buttons were the total opposite in discuss app:
- 'livechat-info' was put as the 1st panel one before panels
- 'view-contact' was dead last.

There are differences, with 'livechat-info' being a panel and 'view-contact' a redirect button. However, each are important buttons for the type of conversation that justify them being in their own group right now. Since the buttons are mutually exclusive by the channel type, there's reason to have them share the same position.

This commit moves the position of 'view-contact' in discuss header thread actions to be the same as 'livechat-info', that is as the 1st action in the list. This makes its position consistent with livechat info, thus agents of live chat and whatsapp would appreciate the 2 button placement being consistent.

Task-5431313

<img width="1760" height="231" alt="Screenshot 2025-12-18 at 21 02 24" src="https://github.com/user-attachments/assets/ee2baf91-0d9a-49ca-91ac-a7781b33e57b" />

Forward-Port-Of: odoo/enterprise#102479