### Issue:
Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2
https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf

Importing such files raises an error:
`Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.`

### Cause:
The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent
https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698

The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error

### Steps to reproduce:
- Install `l10n_be_coda` and switch to the `BE company`
- Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data)
Before the fix, the error is trigger

opw-6071761

Forward-Port-Of: odoo/enterprise#113904

### Issue before this commit:
When sending a payment reminder email for a subscription using the email composer, the template  was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing.

### Steps to reproduce the issue:
1. Install subscription and go to that app
2. Open one subscription
3. Send message > Load template: "Subscription: Payment Reminder"
4. Sentence is incomplete: missing end date of the subscription

### Cause of the issue:
The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template.

### Reason to introduce the fix:
The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer.

opw-6031613

Forward-Port-Of: odoo/enterprise#114839
Forward-Port-Of: odoo/enterprise#111801

Issue:
---
Canonical address is not correctly calculated in non-default lang.

Steps to reproduce:
1- Create a website with 2 lang: en, fr
2- Create a product with a website category.
3- Navigate to the shop in fr.
4- Open the category, then open the product.
5- Open console, and search for canonical.

As you see, in the second language, the canonical address includes the category address which is wrong.
If you visit in the default lang, the canonical correctly refers to the url without category.

Cause:
---
This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself.

opw-6086206

Forward-Port-Of: odoo/odoo#258834

Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee.

It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have:
```
+--------------+
| Shift1 User1 |
+--------------+
```
Add another shift (Shift 2) with User2.
We'll have:
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User1 |
+--------------+
```
instead of
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User2 |
+--------------+
```

Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value.

This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by
```html
<span>Employee</span><span class="..">(Department)</span>
```
in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it,
```xml
<span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/>
```
since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change.
Therefore, whenever a component's value changes
(in our case, Shift1 becomes Shift2), it is never updated.

In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution.

To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render.

opw-6128168

Forward-Port-Of: odoo/enterprise#115160
Forward-Port-Of: odoo/enterprise#115061

Pre-requisites:
---------------
1. Create or duplicate any `hr.applicant` email template.
2. Archive the newly created template.
3. Archive the email template linked to a refuse reason.

Steps to reproduce:
-------------------------
1. Install hr_recruitment.
4. Go to Recruitment > Applications > All Applications and open an applicant.
5. Click on the "Refuse" button to open the refuse wizard.
6. Click on the "Email Template"  and click on 'Search More'
7. Observe available templates

Issue:
-------
If a refuse reason is linked to an archived email template,
the wizard automatically pre-fills that archived template

Cause:
----------
The `_compute_template_id` method automatically assigns
the template from the refuse reason without checking whether
the template is active, which allows archived templates to be
pre-filled in the wizard.
https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96


Solution:
-----------
- Update `_compute_template_id` to ensure only active templates are
  automatically assigned.


opw-5974244




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

Forward-Port-Of: odoo/odoo#257580
Forward-Port-Of: odoo/odoo#251186

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/45f9930d5a [REL] 19.2.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a0c7941d4e [FIX] chart: figure sometime still exist after chart deletion [Task: 6107235](https://www.odoo.com/odoo/2328/tasks/6107235)
https://github.com/odoo/o-spreadsheet/commit/bc9fcef122 [FIX] package: saas-19.2 is no longer the latest stable [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language.

### Steps to reproduce

1. Install the "Surveys" module and activate a second language (e.g., Dutch).
2. Create a survey and ensure its invitation template has translations for both languages.
3. Create two contacts: one with English as their language and another with Dutch.
4. On the survey, click "Share" and add both contacts as recipients.
5. Send the invitations.
6. The contact with Dutch preferred language receives the email in English.

### Cause

By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one.

opw-5868581

Forward-Port-Of: odoo/odoo#259967
Forward-Port-Of: odoo/odoo#246778

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/odoo#261206
Forward-Port-Of: odoo/odoo#257539

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/enterprise#115027
Forward-Port-Of: odoo/enterprise#114786