Description of the issue/feature this PR addresses: Current behavior before PR: The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed. Desired behavior after PR is merged: The "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 --- I confirm I have si

Description of the issue/feature this PR addresses:

Current behavior before PR:
The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed.

Desired behavior after PR is merged:
The  "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 
 



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

Forward-Port-Of: odoo/odoo#184840

### Issue: The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically: The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the si

### Issue:

The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically:

The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the situation.

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

Forward-Port-Of: odoo/odoo#193587
Forward-Port-Of: odoo/odoo#190867

Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit not

Minimal Configuration:
- Create an account (49999 Great Account) that has a default tax (15%)
- Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss)

Steps to reproduce:
- Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%)
- Confirm -> amount = 108.9
- Duplicate the invoice (in the ticket: Create a Credit Note)

Issue:
=> The credit note is not of the same amount = 106.80. That is, MINUS discount * tax_amount <-> 108.90 MINUS 10% * 21= 106.80

Cause:
When there is a "Separate discount accounts on invoices" that is set, discount line appear on the journal items of the document; moves between the default account for such transaction to the chosen move in the settings.
When iterating through those discount lines, the condition was not strict enough to filter them out and would put a tax on them (as my dear colleague Andrea said: the bomb has been planted)

Therefore, when creating a credit/duplicating,  we copy the data  wrongly (but in a correct a way for a standard flow) which gives incoherent results

opw-4166601

Forward-Port-Of: odoo/odoo#193483
Forward-Port-Of: odoo/odoo#187565

Steps to reproduce: - Add a "Call To Action" block on the homepage > Save it as a custom snippet. - Add a new page > Drop the saved custom block on it > Drop Also another "Title" block. - Translate the custom block in the new page > At this point, the translation is fine. - Go to "Edit" mode > Edit the other block ("Title") > Save. - The translations for the custom "Call To Action" is lost. Starting from [1], the translation of custom snippets was supported and when dropping a save

Steps to reproduce:

- Add a "Call To Action" block on the homepage > Save it as a custom
snippet.
- Add a new page > Drop the saved custom block on it > Drop Also
another "Title" block.
- Translate the custom block in the new page > At this point, the
translation is fine.
- Go to "Edit" mode > Edit the other block ("Title") > Save.
- The translations for the custom "Call To Action" is lost.

Starting from [1], the translation of custom snippets was supported and
when dropping a saved custom snippet in a page/view, the snippet will
copy its translation from the saved view (see:
`_copy_custom_snippet_translations()`). This code will always update the
terms in the translation dictionary, even when the page has its custom
translation for them.

The goal of this commit is to fix this behavior by only allowing the
update of a term translation when the page has no custom translation
for it.

[1]: https://github.com/odoo/odoo/commit/d3426b7714012e833caae10281cfb8433223299a

opw-3930862
opw-4141290

Forward-Port-Of: odoo/odoo#194234
Forward-Port-Of: odoo/odoo#177960

- fix the `hr_leave_allocation_rule_employee_update` rule to include `('manager','both') in validation_type` instead of `hr` as those are the types where the emoployee's manager should be able to update - fix `_check_approval_update` function to match the designed access rules where TOO only approve `hr` and validate `both` and manager approvre `manager, both` Task: 4432503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo

- fix the `hr_leave_allocation_rule_employee_update` rule to include `('manager','both') in validation_type` instead of `hr` as those are the types where the emoployee's manager should be able to update
- fix `_check_approval_update` function to match the designed access rules where TOO only approve `hr` and validate `both` and manager approvre `manager, both`

Task: 4432503



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

Forward-Port-Of: odoo/odoo#191808

Steps to reproduce: - Go in time off app -> overview - Search on name Issue: When searching on name, the search does not work. This is due to the name being computed and not stored. Directly related to the [recent changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214) Fix The field has now a search method on the different component of the name separetly. opw-4351362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa

Steps to reproduce:

 - Go in time off app -> overview
 - Search on name

Issue:

When searching on name, the search does not work. This is due to the
name being computed and not stored. Directly related to the [recent
changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214)

Fix

The field has now a search method on the different component of the name
separetly.

opw-4351362

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

Forward-Port-Of: odoo/odoo#188433

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:

-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#161814

At the moment it is not possible to add new X2many relations to a model inside the `SERIALIZABLE_MODELS` list. I would like to add an One2many relation to the `pos.order` model: ```python class PosOrder(models.Model): _inherit = "pos.order" example_items = fields.One2many("example.item", "order_id") ``` ```javascript import { Base } from "@point_of_sale/app/models/related_models"; import { registry } from "@web/core/registry"; export class ExampleItem extends Base {

At the moment it is not possible to add new X2many relations to a model inside the `SERIALIZABLE_MODELS` list.

I would like to add an One2many relation to the `pos.order` model:

```python
class PosOrder(models.Model):
    _inherit = "pos.order"

   example_items = fields.One2many("example.item", "order_id")
```

```javascript
import { Base } from "@point_of_sale/app/models/related_models";
import { registry } from "@web/core/registry";

export class ExampleItem extends Base {
  static pythonModel = "example.item";

  setup(vals) {
    super.setup(vals);
  }

  // ...
}

registry.category("pos_available_models").add(ExampleItem.pythonModel, ExampleItem);
```

A call to [`order.serialize`](https://github.com/abichinger/odoo/blob/f9de1eef6dd403157c0222dc75de85c8b7b59e3c/addons/point_of_sale/static/src/app/models/related_models.js#L191) throws the following error:

```
Trying to create a non serializable record example.item
```

After this PR is merged it is possible to add new models to the list of serializable models:

```javascript
import { SERIALIZABLE_MODELS } from "@point_of_sale/app/models/related_models"
SERIALIZABLE_MODELS.push("example.item")
```

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

Forward-Port-Of: odoo/odoo#181972

When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case. In this commit we fix the issue Task: 4219525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183285 Forward-Port-Of: odoo/odoo#182081

When the session of the kiosk is closed in the backoffice, the kiosk is supposed to show the "We are closed" banner and to no longer accept orders. Currently, this is not the case.

In this commit we fix the issue

Task: 4219525

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

Forward-Port-Of: odoo/odoo#183285
Forward-Port-Of: odoo/odoo#182081

[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go

[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method

Problem:
After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty.

Steps to Reproduce:
1. Install Point of Sale app.
2. Go to Configuration > Settings. Enable any "Payment Terminals".
3. Go to Configuration > Payment Methods. Click new or edit a record.
4. Select a journal
5. Select an "Integration" option "Terminal"
6. Select a terminal in "Integrate with" option
7. Switch an "Integration" option to None
8. Observe that the added fields does not disappear and is still getting validate when you save the record.

Move from #182548: renaming branch

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

Forward-Port-Of: odoo/odoo#182835

Introduced in #184138. When you try to print a receipt using an IoT box that isn't available, there is the option to print using the browser as a fallback. However, clicking this option produces a traceback. Steps to reproduce: - Configure a POS to use an IoT Box Receipt Printer (e.g. the default [Shop] Receipt Printer) - Make sure the IoT box is not reachable - Make an order and try to print the receipt, it should fail and the dialog will appear asking if you would like to use the web pri

Introduced in #184138. When you try to print a receipt using an IoT box that isn't available, there is the option to print using the browser as a fallback. However, clicking this option produces a traceback.

Steps to reproduce:
- Configure a POS to use an IoT Box Receipt Printer (e.g. the default [Shop] Receipt Printer)
- Make sure the IoT box is not reachable
- Make an order and try to print the receipt, it should fail and the dialog will appear asking if you would like to use the web printer
- Select OK, and a traceback will appear

Expected behaviour:
- There is no traceback and the browser printing dialog appears

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

Forward-Port-Of: odoo/odoo#187904

… session action. Description of the issue/feature this PR addresses: 1. Usage of 'tree' in outstanding rescue session action. 2. Missing CLA for contributions. Current behavior before PR: 1. The outstanding rescue session action uses 'tree' . 2. CLA file is not included. Desired behavior after PR is merged: 1. 'list' replaces 'tree' in the outstanding rescue session action. 2. CLA file is added for future contributions. --- I confirm I have signed the CLA and read the PR gu

… session action.

Description of the issue/feature this PR addresses:
1. Usage of 'tree' in outstanding rescue session action.
2. Missing CLA for contributions.

Current behavior before PR:
1. The outstanding rescue session action uses 'tree' .
2. CLA file is not included.

Desired behavior after PR is merged:
1. 'list' replaces 'tree' in the outstanding rescue session action.
2. CLA file is added for future contributions.


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

Forward-Port-Of: odoo/odoo#189379

Steps to reproduce: [l10n_dk] - create and confirm a sale order - create an expense for a new employee and use a product set with reinvoice at cost and a tax with multiple repartition lines - confirm and process the expense - post journal entries Issue: Missing required fields on accountable sale order line. Cause: We want to reinvoice the tax line that no product on it opw-4378714 Forward-Port-Of: odoo/odoo#193853 Forward-Port-Of: odoo/odoo#191163

Steps to reproduce:
[l10n_dk]
- create and confirm a sale order
- create an expense for a new employee and use a product set with reinvoice at cost and a tax with multiple repartition lines
- confirm and process the expense
- post journal entries

Issue:
Missing required fields on accountable sale order line.

Cause:
We want to reinvoice the tax line that no product on it

opw-4378714

Forward-Port-Of: odoo/odoo#193853
Forward-Port-Of: odoo/odoo#191163

**Problem**: In rare edge cases, the selection can have no ranges, causing a crash when attempting to `getRangeAt(0)`. **Solution**: Ensure there are ranges in the selection before accessing them. **Steps to Reproduce**: 1. Split the window, with Odoo on one side and any other application on the other. 2. Navigate to a sales order in Odoo. 3. From the sales order, navigate to the partner. 4. Maximize the window. 5. Return to the sales order. 6. Split the window again. 7. Scroll do

**Problem**:
In rare edge cases, the selection can have no ranges, causing a crash when attempting to `getRangeAt(0)`.

**Solution**:
Ensure there are ranges in the selection before accessing them.

**Steps to Reproduce**:
1. Split the window, with Odoo on one side and any other application on the other.
2. Navigate to a sales order in Odoo.
3. From the sales order, navigate to the partner.
4. Maximize the window.
5. Return to the sales order.
6. Split the window again.
7. Scroll down.

opw-4279813

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

Forward-Port-Of: odoo/odoo#194385

add missing translated terms that have been omitted in https://github.com/odoo/odoo/pull/188819 Forward-Port-Of: odoo/odoo#194497

add missing translated terms that have been omitted
in https://github.com/odoo/odoo/pull/188819

Forward-Port-Of: odoo/odoo#194497

With this PR : ------------------------------------------ - Addressed an issue where components added after MO confirmation were not being automatically consumed during production. - Implemented checks and updates in function to ensure all components are marked as picked before production. - This fix ensures that all components, including those added after MO confirmation, are properly accounted for and consumed during the production process. Task-id : 3951176 Forward-Port-Of: odoo/odoo#

With this PR :
------------------------------------------
- Addressed an issue where components added after MO confirmation were not being automatically consumed during production.
- Implemented checks and updates in function to ensure all components are marked as picked before production.
- This fix ensures that all components, including those added after MO confirmation, are properly accounted for and consumed during the production process.

Task-id : 3951176

Forward-Port-Of: odoo/odoo#168716

- Avoid duplicating ticket in preparation display when paying a split order. - Inside `pos_preparation_display.sync_from_ui` only call `process_order` if `pos_restaurant` is not installed in the config. Steps to Reproduce: - Add items to the cart and confirm an order. - A preparation is created in the PD (correct behavior). - Go back to the table, split the order, and pay for some lines. - Previously, a duplicate preparation card was created for split lines in the PD (incorrect behavior

- Avoid duplicating ticket in preparation display when paying a split order.
- Inside  `pos_preparation_display.sync_from_ui` only call `process_order` if `pos_restaurant` is not installed in the config.

Steps to Reproduce:
- Add items to the cart and confirm an order.
- A preparation is created in the PD (correct behavior).
- Go back to the table, split the order, and pay for some lines.
- Previously, a duplicate preparation card was created for split lines in the PD (incorrect behavior).

community PR: https://github.com/odoo/odoo/pull/193692

task-id: 4476871

Forward-Port-Of: odoo/enterprise#77150

Before this commit, when searching after an empty order, sometime a finalized order was returned. This commit fixes the issue by only checking open orders. Forward-Port-Of: odoo/enterprise#77428

Before this commit, when searching after an empty order, sometime a finalized order was returned.

This commit fixes the issue by only checking open orders.

Forward-Port-Of: odoo/enterprise#77428

…ique FITID To replicate the issue: 1. Install the brazilian localization (enterprise) 2. In the accounting app dashboard, click Import Statement 3. Upload an .OFX file with duplicate FIDID 4. A validation error appears and the upload is not done Cause: The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions wi

…ique FITID

To replicate the issue:
1. Install the brazilian localization (enterprise)
2. In the accounting app dashboard, click Import Statement
3. Upload an .OFX file with duplicate FIDID
4. A validation error appears and the upload is not done

Cause:
The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions with the same FITID. An example is when PIX transfers have the same FITID as the fee charged for the PIX, which appears as another bank statement line with the same FITID.

Fix:
The function _parse_bank_statement_file is altered to call a function that fills the vals_line dictionary with the transaction's values. This function is then overwritten in l10n_br_reports to not include the FITID (unique_import_id) for journals of Brazilian companies.

opw-4317681

Forward-Port-Of: odoo/enterprise#77381
Forward-Port-Of: odoo/enterprise#76556

Before this commit, the button label displayed as 'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label. After this commit, the button label is now dynamic and

Before this commit, the button label displayed as
'Comparison: <previous_period>' (where 'previous_period' was the period preceding the compared period), regardless of the comparison type selected. For example, if comparing October 2024 to previous months, the label would appear as 'Comparison: Sep 2024'. This caused confusion for users when comparing a period to multiple previous ones, as only the last period was displayed in the label.

After this commit, the button label is now dynamic and reflects the selected comparison:
- When comparing to previous periods: 'Comparison: <periods_number> Previous Periods'
- When comparing to the previous period: 'Comparison: Previous Period'
- When comparing to the same period in previous years: 'Comparison: <periods_number> Previous Years'
- When comparing to the same period in the previous year: 'Comparison: Previous Pear'
- When we don't compare to another period/year: 'Comparison'

Here, 'periods_number' refers to the number of periods or years being compared.

task-id: 4267209

Forward-Port-Of: odoo/enterprise#77179
Forward-Port-Of: odoo/enterprise#73944

**Problem**: When splitting a document, the `output` should include the attachments from the `input_pdf`. Currently, the attachments are missing in the output after splitting. **Steps to reproduce**: 1. In the Documents app, upload a PDF that contains attachments (example file provided in the ticket). 2. Split the uploaded PDF. 3. Preview the split file and check the left panel. 4. Notice that the attachments are missing in the left panel. opw-4191327 Forward-Port-Of: odoo/enterprise

**Problem**:
When splitting a document, the `output` should include the attachments from the `input_pdf`. Currently, the attachments are missing in the output after splitting.

**Steps to reproduce**:
1. In the Documents app, upload a PDF that contains attachments (example file provided in the ticket).
2. Split the uploaded PDF.
3. Preview the split file and check the left panel.
4. Notice that the attachments are missing in the left panel.

opw-4191327

Forward-Port-Of: odoo/enterprise#77450
Forward-Port-Of: odoo/enterprise#74989

Steps to reproduce: --- 1) Go to a Subscription with a Project 2) Add a section and/or note line 3) Navigate Project smart button -> Dashboards -> Subscription dropdown 4) Notice the order lines Issue: ---- In the subscription the sections and notes are taken into account this is due to the fact that all the line are retrieved and not only the "billable". Fix: --- Adding a condition on the display type of the line. opw-4394767 Forward-Port-Of: odoo/enterprise#77176

Steps to reproduce:
---
1) Go to a Subscription with a Project
2) Add a section and/or note line
3) Navigate Project smart button ->
Dashboards -> Subscription dropdown
4) Notice the order lines

Issue:
----
In the subscription the sections and notes are taken into account this is due to the fact that all the line are retrieved and not only the "billable".

Fix:
---

Adding a condition on the display type of the line.

opw-4394767

Forward-Port-Of: odoo/enterprise#77176

The value sent from IAP was never sent. So what was printed was always None. So we remove its uses (and will change the method definition in non-stable Forward-Port-Of: odoo/enterprise#77102

The value sent from IAP was never sent.
So what was printed was always None.
So we remove its uses (and will change the method definition in non-stable

Forward-Port-Of: odoo/enterprise#77102

## Description - when applying sort by for a non-stored field in a list view, it leads to traceback. - when fetching data, when attempting to convert it into an SQL query, now throws error after this [commit](https://github.com/odoo/odoo/commit/fb0569eeba0a8909a067f2ad90b80edbe8d2d915), form this [line](https://github.com/odoo/odoo/blame/de47ec932742ef82b315990cbac8787f82aa91d5/odoo/models.py#L2846) - This pr ensures that only stored fields are available for sorting in the list view editor,

## Description

- when applying sort by for a non-stored field in a list view, it leads to traceback.
- when fetching data, when attempting to convert it into an SQL query, now throws error after this [commit](https://github.com/odoo/odoo/commit/fb0569eeba0a8909a067f2ad90b80edbe8d2d915), form this [line](https://github.com/odoo/odoo/blame/de47ec932742ef82b315990cbac8787f82aa91d5/odoo/models.py#L2846)
- This pr ensures that only stored fields are available for sorting in the list view editor, preventing such issues.


## steps to reproduce
- Start a db ( version 17.2 or greater)
- install studio and contacts app
- open studio editor for contact app's list view.
- Add display_name in list and set `sort by` attribute with `display_name` field. 

## Traceback
```py
File "/home/odoo/odoo/codebase/odoo/saas-17.2/addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/addons/web/models/models.py", line 46, in web_search_read
    records = self.search_fetch(domain, specification.keys(), offset=offset, limit=limit, order=order)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 1626, in search_fetch
    query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5454, in _search
    query.order = self._order_to_sql(order, query)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5266, in _order_to_sql
    term = self._order_field_to_sql(alias, field_name, sql_direction, sql_nulls, query)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 5324, in _order_field_to_sql
    sql_field = self._field_to_sql(alias, field_name, query)
  File "/home/odoo/odoo/codebase/odoo/saas-17.2/odoo/models.py", line 2846, in _field_to_sql
    raise ValueError(f"Cannot convert field {field} to SQL")
ValueError: Cannot convert field res.partner.display_name to SQL

```

Forward-Port-Of: odoo/enterprise#77467
Forward-Port-Of: odoo/enterprise#76351

This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill. To handle this issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues. There was also a `z-index` is

This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill.  To handle this
issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues.

There was also a `z-index` issues with the connectors, the one at the bottom being hidden by the pill below. To fix the issue, we handle the `z-index` at the pill wrapper level to ensure it gets the right elevation.

| 17.0 | This PR |
|--------|--------|
| <img width="366" alt="image" src="https://github.com/user-attachments/assets/f14d3c98-c2d5-4215-90ec-3cbe97b3ea56"> | ![image](https://github.com/user-attachments/assets/0afb1ddc-9471-4976-85c2-c31adba2ec1d) | 

task-3865935

Forward-Port-Of: odoo/enterprise#77420
Forward-Port-Of: odoo/enterprise#74859