…workflow

This commit integrates the Dutch SBR tax reporting process into the `account.return` workflow to provide better visibility, UI feedback, and tracking for users.

Main changes:
* Added a new `l10n_nl_sbr_status` field (Pending, Accepted, Error) to `account.return` to track the submission status for Kanban UI color coding.
* Updated the Kanban view to dynamically apply custom CSS classes (`nl-sbr-error`, `nl-sbr-pending`) to the state bubble based on the SBR status.
* Introduced an `action_refresh_sbr_status` method and a corresponding "Refresh" button in the Kanban view to manually trigger the status check cron.
* Consolidated Chatter messages so that status updates, errors, and submission success notifications log directly on the `account.return` record rather than the closing entry.
* Added an `action_reset_tax_return_common` override to prevent resetting or modifying a tax return once it has been accepted by Digipoort.
* Modified the UI to hide the "Pay" button unless the SBR return has been fully accepted.
* Updated `_on_post_submission_event` to block further processing of the return until the SBR report is accepted.

task-6034675

Forward-Port-Of: odoo/enterprise#110516

### Issue:
When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected

### Cause:
SIRET values must be exactly 14 characters long
However, spaces were not removed when generating the XML, leading to invalid values in:
`<cbc:ID schemeID="0009">` and `<cbc:CompanyID schemeID="0009">`

This issue can occur for both the company and the customer SIRET, as both rely on `company_registry`

As a result, Chorus Pro rejects the document due to invalid SIRET length

### Steps to reproduce:
- Install `l10n_fr_facturx_chorus_pro` and switch to `FR Company`
- Enable and Activate Peppol in Settings
- Go in Settings > Users & Companies > Companies and open the `FR Company`
- Add spaces in the Company ID: 968 515 7590 5808
- Create a Customer (Country: France, VAT: FR23334175221, Company ID/Siret: 123 456 7890 1234)
- In the customer's Invoicing Tab (Invoice sending: by Peppol, eInvoice format: EU Standard (Peppol Bis 3.0), France SIRET: 11000201100044)
- Create and Send an invoice via Peppol (Your Customer, any line with a tax)
- Open the XML
- Check the IDs and CompanyIDs in the document Before the fix, there is missing spaces

opw-6047840

Forward-Port-Of: odoo/odoo#260578

### 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

When a menu item URL contains a space and has no leading slash (e.g.,
"some url"), creating a page from its 404 screen does not link the menu
to the newly created page. The menu keeps pointing to a 404.


**Steps to reproduce**:
1. Create a menu item with a URL containing spaces and no leading slash
   (e.g., "some url").
2. Click the menu item -> a 404 page is displayed (expected).
3. Click "Create Page" -> the page is created and saved.
4. Click the menu item again -> it still returns a 404 (unexpected).


**Issue**:
During page creation, the path is slugified (e.g., "some url" ->
"/some-url"). The controller then tries to link the menu to the new page
by setting `page_id`. However, `pagenew()` only searches for menu URLs
with a leading slash, so a menu saved as "some url" is not found when
searching for "/some url". As a result, `page_id` is never set, and
`_clean_url()` keeps resolving the menu to "/some url" instead of the
page's actual URL "/some-url".

Menus without spaces (e.g., "mypage") have the same issue where
`page_id` is not set, but since `_clean_url()` prepends "/" and renders
"/mypage", which matches the new page URL, the menu still resolves
correctly.


**Fix**:
Match both URL formats (with and without leading slash) when linking a
menu to a newly created page.

Additionally, a warning is now shown in the menu editor when a URL
contains spaces, since spaces are slugified during page creation,
which could cause confusion. (Note: this is only a warning - URLs with
spaces are still allowed.)

task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646)

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

Forward-Port-Of: odoo/odoo#261208
Forward-Port-Of: odoo/odoo#248967

Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document.

The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484
Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`).
As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`.

This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state.

The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios.

The most common setup where the error happens is for invoices that have 2 DIAN documents:
1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`)
2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events)

opw-6108318
opw-5931442
opw-6034035

Forward-Port-Of: odoo/enterprise#113929

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4e3d2038e4 [REL] 19.1.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d21a87b75b [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098)
https://github.com/odoo/o-spreadsheet/commit/201f1ba213 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098)

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>

Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account.

When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied.

On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to
 any journal item.

To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines.

opw-6107329

Forward-Port-Of: odoo/enterprise#114863

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

Issue:
----------------------------------------
With a specific configuration it can happen that overtime lines are not deleted when regenerating them, causing crashes in `_set_real_overtime_intervals()` for example, because several records will be linked in the same interval.

Steps to reproduce:
----------------------------------------
- Have a calendar where:
	- Attendance on Sunday
	- No attendance on Monday
	- Timezone = 'America/New_York'
- Select this calendar for an employee in UTC timezone with the default overtime ruleset
- Create an attendance for this employee:
	- Start: 10AM on a Sunday
	- End: 1AM the next day, Monday
- It should have 2 overtimes, one on Sunday the other on Monday
- Go on the ruleset and click "Regenerate ovetimes"
- Go back to the attendance and notice the overtime line for Monday is duplicated
- If you go in Payroll > Work Entries > Work Entries and select the time frame to see the attendance, it will crash

Cause:
----------------------------------------
We use `_get_tz()` to get the timezone in which we want to convert the attendance start and end to, then create the domain to search for the overtimes. But `_get_tz()` returns the calendar timezone, not the resource one, which is the one used in the attendance and overtime lines dates.

When converting the start and end of the attendance to calendar tz, they both end up on Sunday. So the domain includes the whole week before the attendance but not the Monday where there is an overtime line. So only the Sunday overtime line is selected, and only this one is [unlinked](https://github.com/odoo/odoo/blob/ca8f3e6f054748e8951a2cd05ccdc2d36388e928/addons/hr_attendance/models/hr_attendance.py#L304) leaving the one on Monday, which is later recreated.

Solution:
----------------------------------------
Use `employee.tz` instead of `_get_tz()`.

opw-6067969

Forward-Port-Of: odoo/odoo#259809

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#260815
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#114786

Steps:
- Install ai
- Open ai chat
- Try to send a message
- Traceback

The AI chat was failing on iOS with a traceback when trying to process
the stream response.

Even though MDN suggests compatibility, Safari (WebKit) versions prior
to 26.4 do not implement the AsyncIterator protocol on ReadableStream.
This makes `for await (const chunk of response.body)` throw a TypeError
as `[Symbol.asyncIterator]` is undefined.

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

This commit replaces the async iteration with a manual reader loop
(`getReader().read()`). This is the low-level primitive supported by
all versions of Safari and ensures the stream is properly consumed and
unlocked even if the connection is interrupted.

Steps to reproduce:
1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4).
2. Send a message.
3. The response triggers a JS error.

```js
Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...')
```

opw-6054307

Steps to reproduce:
- Create a product P1 with a BoM containing component C1
- Set C1 route to MTO + Buy:
    - add any vendor
- Have 10 units of C1 in stock

- Confirm a Manufacturing Order for 2 units of P1
- The MO confirmation triggers the move for C1, which gets assigned from stock
- Increase the quantity_producing on the MO
- This updates product_uom_qty on the move and calls _run_procurement

Expected behavior:
- No Purchase Order should be created since stock covers the demand

Current behavior:
- A Purchase Order is created even though stock is sufficient
- In case of partial stock, the full procurement_qty is used instead of the uncovered delta

Fix:
- Track mts_else_mto moves separately before calling _action_assign()
- After _action_assign(), subtract the newly covered quantity (move.quantity - old_qty)
  from the procurement_qty before running the stock rule
- Skip the procurement entirely if the adjusted qty <= 0

opw-6042283

Forward-Port-Of: odoo/odoo#258871

Bug introduced in: https://github.com/odoo/odoo/commit/385e4cab3ba6d3b2c4975565125389eb07f2ef45

Steps to reproduce:
- Create a new database with only the Purchase module installed
- Enable the "Units of Measure & Packagings" option
- Create a storable product "P1" with the following vendor pricelist:
  - Vendor: Azure Interior (1 pack of 6 for $10)
- Create a purchase order:
  - Vendor: Azure Interior
  - Quantity: 3 packs of 6 of P1
- Confirm the PO
- Click the Receive button (available without the Stock module since v19.1)

Problem:
1:/
Expected behavior: qty_received = 3 (in purchase UoM: packs of 6)
Actual behavior:   qty_received = 18 (product UoM: units)

`product_uom_qty` (expressed in the product's UoM) was used instead of `product_qty` (expressed in the purchase line's UoM) when computing `qty_received`. Since `qty_received` feeds into `quantity_to_invoice`, this caused the invoicing autocomplete to suggest 18 packs of 6 instead of the correct 3 packs of 6.

2:/
The parameter `invalid_targets` was not properly passed to the
translation function in the error message, causing a traceback
when trying to receive a PO in an invalid state.

opw-6080527