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

When the client subscribes to new channels, it passes its last known notification id as the starting point of the stream.

For the very first connection, the last id defaults to 0. In this case, the server replays notifications from the last 50 seconds. This heuristic can lead to missed notifications (e.g. if the WebSocket fails to connect and retries exceed the window).

When the last_id is outdated, the server may dispatch a large number of notifications which can consume memory and CPU for nothing (e.g. when reconnecting after a long period of inactivity).

This commit fixes both issues by providing an explicit starting point for the bus service. The server includes the latest bus id in the session information at page load.

This ensures that no old notifications are fetched, and none are missed: initial data is fetched after page load, and any notifications emitted between that moment and the successful WebSocket connection are delivered, since the subscription starts from the server provided last id.

task-6144132

https://github.com/odoo/enterprise/pull/115105

The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color didn't participate in the CSS variable system. Whenever a user set a custom Content Background color and a border-radius on a text block, the corners would reveal white underneath instead of the actual Content Background color.

Removed the `bg-white` class from the template and set white as the proper default for the `--wrapper-background-color` variable instead, so the wrapper is still white by default but correctly responds to the Content Background color picker.

Steps to reproduce:
1. Create a new Mailing
2. Set the Content Background color to something other than white
3. Add a Text block
4. Set a border-radius value on the block

=> white shows behind the rounded corners instead of the Content Background

Ticket [link](https://www.odoo.com/odoo/project.task/5868955) 
opw-5868955

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

Forward-Port-Of: odoo/odoo#247808

Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule.

Steps to replicate:
- Install `accountant` with demo, turn on `Analytic Accounting` from settings.
- Open `Accounting > Review > Depreciation Schedule`.
- Click `Analytic` > Add a `Plan`.

Error:
```
psycopg2.errors.UndefinedFunction: operator does not exist: text = record
LINE 12:             WHERE key IN (('7', '16', '8', '15', '6', '9', '...
                               ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

Cause:
- At line [1], we pass a tuple of `analytic_account_ids`, which is then wrapped again in parentheses at line [2].

- This results in the IDs being enclosed in double parentheses, e.g. `(('7', '16', '8', '15', '6'))`.

- When the `IN` clause is used with this double-parenthesized tuple, PostgreSQL treats it as a list containing a single record. It then tries to compare `key` (a text value) with that record `('7', '16', '8', '15', '6')`, effectively resulting in a `text = record` comparison, which is invalid and causes error.

Solution:
- Removed the extra parentheses from the query.

[1]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L124

[2]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L121

sentry-7423121981

Forward-Port-Of: odoo/enterprise#114334

### 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:
If a payslip is split into multiple bank accounts (Salary Allocation), the generated SEPA file contains duplicate <InstrId> tags

### Cause:
The `_get_payments_vals` method, `InstrId` is based on the payslip ID
When a single payslip generates multiple transaction blocks, this ID is duplicated, violating the ISO 20022 requirement for unique instruction identifiers
https://knowledge.xmldation.com/support/iso20022/general_rules/instrid

This commit adds a unique suffix with the bank_account.id (slip.id-ba.id) to the `InstrId` for each transaction generated to ensure technical uniqueness

This is the part of the code that use the payment name:
https://github.com/odoo/enterprise/blob/194a8d35ef3e9b47ff566479b0c35c0f963fb42d/account_iso20022/models/account_journal.py#L294-L299

### Steps to reproduce:
- Install `hr_payroll_account_iso20022` with demo data
- On the Bank Journal, set a valid IBAN (e.g. BE04957751619131) for `Bank Account Number`
- Open the Employee page for Abigail Peterson
- In the Personal tab, add 2 Bank Accounts (Send Money: True, Account Number: any)
- Click on Salary Allocation and Save (You'll have a 50/50 ratio)
- Create a new Pay Run (for Abigail Peterson)
- Open the last PaySlip and Validate
- Create Payment Report (Export Format: SEPA)
- Download the Payment Report and check the <InstrId> tags

opw-6069670

Forward-Port-Of: odoo/enterprise#114325
Forward-Port-Of: odoo/enterprise#113113

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

Creating or updating an attendance record resets previously approved overtime entries in the same week back to the 'to_approve' status.

### **Steps to reproduce:**
1) Install Attendance with demo data.
2) Set 'Extra Hours Validation' to 'Approved by Manager' in settings. 
3) Ensure an overtime rule is set for the Admin user. 
4) Create an attendance for Admin with some overtime.
5) Navigate to management and approve overtime.
6) Create another attendance with overtime for Admin in the same week. 
7) Navigate back to management.

### **Observed Behavior:**
Previously approved overtime reappears in the list, requiring approval again.

### **Expected Behavior:**
Previous overtime should remain in the 'approved' status, provided its calculated duration has not changed.

### **Root Cause:**
When an attendance is added or modified, the [_get_overtimes_to_update_domain](https://github.com/odoo/odoo/blob/3891dd471d64629634644c0b022a171bbaa65b49/addons/hr_attendance/models/hr_attendance.py#L268-L286) method
evaluates the entire week regardless of the ruleset. This means any
daily attendance update wipes and recreates the entire week.

### **Fix:**
Check the ruleset of the employee. If no rule has `quantity_period` set to
**'week'**, restrict the domain to the specific days of the attendances being
modified, rather than the entire week.

**opw-6054497**

Forward-Port-Of: odoo/odoo#260723
Forward-Port-Of: odoo/odoo#256281

Steps to reproduce:
-------------------
1. Set up a POS with a currency different from the company currency (e.g. company in USD, POS in SSP).
2. Create a USD pricelist with a surcharge rule (e.g. +10 USD on list_price).
3. Create an SSP pricelist that references the USD pricelist as its base (base = "pricelist"), with an additional discount rule.
4. Assign the SSP pricelist to the POS and add a product.

-> The displayed price ignores the currency conversion between the two pricelists: surcharges/discounts are applied as if both pricelists share the same currency.

What's happening:
-----------------
The POS pre-converts product prices from company currency to POS currency in `_load_pos_data_read`. However, `getPrice` in JS never converts between the POS currency and the pricelist's own currency before applying the rule's formula (surcharge, discount, etc.).

The fix:
--------
In `getPrice`, convert the price from POS currency to pricelist currency before applying the rule, then convert back afterward.

Note that we have changed the loading order of the models for `pos_self_order`, such as 'res.currency' records are loaded after 'product.pricelist' ones, because now the loaded currencies depend on the loaded pricelists.

opw-6013513

Forward-Port-Of: odoo/odoo#260797
Forward-Port-Of: odoo/odoo#255357

edit : the issue was fixed by https://github.com/odoo/odoo/pull/257103
So this commit only contains these use cases tests

**Steps to reproduce:**
- enable consignement setting
- create a tracked avco product with a cost of 10
- click on the quantities smart button and then 
"update quantity" to open the quants view
- create one line with a quantity of 1 and no owner
- create one line with a quantity of 1 and an owner 
outside the company

**Current behavior:**
problem A: 
open the 'stock' view and look for your product, 
the unit cost is 5

problem B: 
navigate back to the quants view of the product, unhide
the value column, the value is 5 for the non consigned
quant

**Expected behavior:**
problem A: 
the unit cost should be 10 (because consigned product 
shouldn't be taken into account when computing the 
unit cost)

problem B: 
the non consigned quant value should be 10 
for the same reason 

**Cause of the issue:**
problem A: 
Inside _compute_value(), to compute total_value_by_company_id, 
we use _with_valuation_context()
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L196-L203
which excludes consigned products
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L362-L364
So when we iterate through 'products' and fetch 
qty_available for our product the value is 
going to be 1. 

But when computing avg_cost at the end of 
the method, we iterate through 'self', so we 
don't have this context anymore and the value 
of qty_available is 2. 
https://github.com/odoo/odoo/blob/6c107cd70e2228d3428e53cf8095aba17f678d8a/addons/stock_account/models/product.py#L271-L273
That's because qty_available is computed 
with _compute_quantities() which depends on 
context (including owner_id)
https://github.com/odoo/odoo/blob/53f7d1dd2f972921ba91f6083a49f50749a3f503/addons/stock/models/product.py#L148-L152

problem B: 
when computing the value of the quant, 
there is no context specifying that the consigned
quantities should be excluded
https://github.com/odoo/odoo/blob/53f7d1dd2f972921ba91f6083a49f50749a3f503/addons/stock_account/models/stock_quant.py#L61-L62

opw-6049413

Forward-Port-Of: odoo/odoo#260392
Forward-Port-Of: odoo/odoo#257013