Issue before this commit:
=========================
The draft progress segment in the manufacturing order Kanban view is barely 
visible against the background.
<img width="442" height="145" alt="image" src="https://github.com/user-attachments/assets/9ba3e4ef-7b91-4c82-86ee-1fe0e47f472f" />


Steps to reproduce:
===================
- Install MRP.
- Create a draft manufacturing order.
- Open the manufacturing orders in the Kanban view.
- Observe the progress bar and notice that the segment representing the
  draft state is barely visible

Cause of the issue:
===================
In this [commit](https://github.com/odoo/odoo/pull/251475/changes#diff-3bad372563263ef117de6ed9e222008e2a27b2ea212df89f72f269066a8eacacR603) the manufacturing order Kanban progress bar was 
changed to represent order states. Draft orders were assigned the `light` color, which 
blends into the Kanban background and makes their segment barely visible.

After this commit:
==================
The progress segment for the draft state is clearly visible, allowing users to
easily distinguish draft orders in the Kanban view.
<img width="343" height="123" alt="image" src="https://github.com/user-attachments/assets/6646143f-a299-4544-b8b5-115e13ebf8c5" />

The "Outstanding credits" or "Outstanding debits" sections of a Credit Note or Vendor Bill will overflow when the "Bill Reference" is too long.

We resolve this by applying the text-truncate class.

Steps to Reproduce:
1. Create a new 19.0 db and load demo data.
2. Accounting -> Vendors -> Refunds -> RBILL/2026/09/0001
3. Click the entry in the Outstanding credits section.
4. Enter a long "Bill Reference" value, e.g. asdf asdfasfasdfasdfasdfasdfasdfasdfasdfasdfasdf.
5. Go back to the Credit Note and observe the text overflow.

opw-6558982

<img width="1254" height="1162" alt="bill_reference_long" src="https://github.com/user-attachments/assets/8c762b50-65a8-44bf-9a28-bd34887d5928" />

<img width="1620" height="1294" alt="overflow" src="https://github.com/user-attachments/assets/f5c47404-fb7f-4715-8815-cabe5dda3805" />

<img width="1586" height="1159" alt="truncated" src="https://github.com/user-attachments/assets/2a80f656-0a12-4805-9c1d-fd20379655ce" />

Forward-Port-Of: odoo/odoo#288389

## Issue
Currently, the different options for the approval of a time off (allocation) request are the following:
1. None needed
2. By Time Off Officer
3. By Employee's Approver
4. By Employee's Approver and Time Off Officer

On the Employee's view form, in the Settings tab, the approvers are named:
1. HR Responsible
2. Time Off

The *By Time Off Officer* option does not notify the *Time Off* approver, but the *HR Responsible*, which is not clear for the users. It would be clearer to use a similar naming convention for both the Approvers on the Employee's form and the options for the approval of the time off (allocation) requests.

<img width="1878" height="592" alt="6535827" src="https://github.com/user-attachments/assets/bc7ad9bb-6b53-4553-8fc8-fb305e7c0b28" />

## Steps to reproduce
1. Install *Time Off* (`hr_holidays`)
2. For an Employee E, set an HR Responsible and a (different) Time Off approvers
3. Create a Time Off request for the Employee E
    - Ensure that the selected Time Off Type has its approval method set to "By Time Off Officer"
4. **The user notified off the time off request is the HR Responsible, which is unexpected, considering that we expect an approval from the "Time Off Officer".**

## Justification
In the `_get_responsible_for_approval` method, when using the "By Time Off Officer" option (`'hr'`), it is clearly the `hr_responsible_id` (HR Responsible) who is selected as "responsible" for the approval.

https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave.py#L1557-L1559

The exact same logic is applied for the allocation requests [here](https://github.com/odoo/odoo/blob/dbed91769c48768f58b6a66bff0ed6d90394de38/addons/hr_holidays/models/hr_leave_allocation.py#L1070-L1072).

## Targeted version
We are targeting version 19.2, as it is the version from which the `responsible_ids` field (which was clearly specifying who had to be notified for the approval of a time off request) was removed (see https://github.com/odoo/odoo/commit/d37cf89a6ff134988b4a7c001a97973cd95a2ea8).

If deemed interesting, the same modification can be backported to previous versions too.

opw-6535827

Forward-Port-Of: odoo/odoo#287686

# How to reproduce
- Go to Sign > Templates
- Upload a PDF & click on Share
- Copy the link
- Go to a page with a EditInBackend systray item (e.g. a Product or Event page)
- In the editor, add the copied link to a button or some text
- Save
- While still in editor mode, click the link

# The issue
A traceback is shown

# Cause
The traceback is caused by the call to this function : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L336

In our case, `this.currentWebsite.metadata.mainObject` is undefined, so trying to access `.model` throws. `mainObject` is undefined because the sign link opens an XML file, which does not have any metadata associated to it :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/services/website_service.js#L150-L155

The call to `getUserModelName` is done by the `EditInBackendSystrayItem` component which subscribes to the "CONTENT-UPDATED" event : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/edit_in_backend.js#L33

However, this method should not be called by the bus because the sign page does not have this systray item. The issue is, the display of the component is managed by the `WebsiteSystrayItem`, based on the `hasEditableRecordInBackend` getter :
https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.js#L10 https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/client_actions/website_preview/website_systray_item.xml#L9

And the re-render of that component that would remove the `EditInBackendSystrayItem` component is triggered by a call to `renderAndAdapt`, which is also subscribed to "CONTENT-UPDATED" : https://github.com/odoo/odoo/blob/f8c29412e71af098b2949f485a8011b01b64b368/addons/website/static/src/components/navbar/navbar.js#L48

So the destroy of the `EditInBackendSystrayItem`, which should remove the listener that calls `getUserModelName` is trigerred AFTER the call to that function is already done

opw-6443794

Forward-Port-Of: odoo/odoo#281763

Clicking a stale /web/content/<id> link in an HTML field crashed the client after the related attachment had been deleted.

**Steps to reproduce:**
1. Open any record with an HTML field (e.g. Project > Task description).
2. Upload a file into the HTML field to embed an attachment link.
3. Save the record.
4. Delete the uploaded attachment from Chatter > Files, or from Settings > Technical > Attachments.
5. Reopen the record and click the embedded file link.

**Client Error:**

   `TypeError: Cannot destructure property 'mimetype' of '(intermediate value)' as it is undefined at LinkPopover.loadAsyncLinkPreview`

`TypeError: Cannot destructure property 'type' of '(intermediate value)' as it is undefined at LinkPopover.updateDocumentState`

When the attachment is missing, ormService.read returns an empty array, so fetchAttachmentMetaData returned undefined instead of entering its catch block. LinkPopover then crashed while destructuring that result in loadAsyncLinkPreview and updateDocumentState.

Return a safe fallback metadata object when the attachment cannot be found so both code paths keep working without crashing.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#279281

**Steps to reproduce:**
- Open Discuss app
- Open any conversation
- Setup the browser with throttled connection (e.g. Slow 4G)
- Select multiple files to attach but don't send the message
- While some are loading, double click the delete button of one of the loaded attachment preview
- Traceback will appear: `404 Not Found`

**Issue:**
On click the delete button triggers a deletion request on `/mail/attachment/delete`.

Repeatedly clicking the delete button before the first request was completed (and the `AttachmentList` get updated) but after the attachment was deleted, will cause a `404 Not Found` due to the `raise NotFound()` which was added by [1] in `mail_attachment_delete`.

```py
attachment = request.env["ir.attachment"].browse(int(attachment_id)).exists()
if not attachment or not attachment._has_attachments_ownership([access_token]):
    request.env.user._bus_send("ir.attachment/delete", {"id": attachment_id})
    raise NotFound()
```

**Fix:**
Prevent concurrent deletion requests for the same attachment by keeping track of attachments currently being deleted.

[1] https://github.com/odoo/odoo/commit/50f45dd436b97027cb1461410efeee7057dad4e8#

opw-6499125

Forward-Port-Of: odoo/odoo#288371
Forward-Port-Of: odoo/odoo#285060