Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#263064
Forward-Port-Of: odoo/odoo#249793

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#262665
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Problem:
The abandoned cart reminder can crash when Click & Collect is enabled. The stock availability check reaches website_sale_collect._get_product_available_qty(), which assumes request.cart always exists.

Solution:
Safely access the cart with hasattr and fall back to the existing no-cart behavior when it is unavailable.

Why:
Scheduled actions may have a request object without a frontend cart. This fix prevents the cron from failing while sending abandoned cart reminders.

Reproduction Steps:
- Configure the website with a warehouse.
- Create/publish a delivery method with delivery type “Pick up in store”. Confirm the website has both
warehouse_id and in_store_dm_id
- Create a cart from the website shop using a storable product that has does not have "Sell When Out of Stock" turned on.
- Leave the cart without checking out.
-  On the generated quotation set the date to the past, but also the date must be after the website.send_abandoned_cart_email_activation_time
- Run the abandoned cart reminder scheduled action for the eligible abandoned cart with a storable product.

Related Ticket:
opw-6133986

Related PR:
https://github.com/odoo/odoo/pull/242864

Forward-Port-Of: odoo/odoo#261885

Issue:
---
In `tax included` companies, the down payment section is not correctly calculated.

Steps to reproduce:
- Configure selected company's field account_price_include to be "tax_included"
- Create a sales order
- Create 1 or more down payment invoices for the SO and confirm
- Create a final invoice that pays for the rest of it
- On this final invoice where the down payment(s) are also listed, click on the preview button

Current behavior:
- The down payment section's total is the sum of the subtotal

Expected behavior:
- The down payment section's total should be the sum of the totals

Justification:
---
The amounts included in the invoice report are dependent on the
`company_price_include` field in `res.partner`. If tax_excluded,
subtotals are listed. If `tax_included`, totals are listed.
There was a mismatch between the entries and the section total;
the section entries could have the total as the amount while
the section's sum would be in terms of subtotals.

Fix:
---
On stable we can still rely on `section_subtotal` but set its
amount to total instead of subtotal in case of `tax_included`.

However, this fix is not stable as there is a xpath on `t-set`
expression in `l10n_ar`.
To avoid breaking the views, we can re-set the `section_subtotal`
in the next lines.
This would still cause issues as it will replace the overridden
logic in the `l10n_ar` implementation.
To prevent that issue, we can re-set the `section_subtotal` only
if the value is the same as `get_section_subtotal`, which means
we are in the main implementation and it's safe to re-set the value.

opw-6127615

Forward-Port-Of: odoo/odoo#262364
Forward-Port-Of: odoo/odoo#261372

Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account

Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.

Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.

[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7

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

Forward-Port-Of: odoo/odoo#263246
Forward-Port-Of: odoo/odoo#260261

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#262665
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

This commit fixes two issues regarding the filmstrip in the /shop page :

- Adding a minimum height to the elements of the `default` and `bordered` designs, so that their heights remain consistent whether they contain an image or not.
- Display a placeholder image for the `images` filmstrip if empty.

task-5491550

| Before | After |
|--------|--------|
| <img width="613" height="103" alt="image" src="https://github.com/user-attachments/assets/852ef2ce-6265-4622-9e30-4e8112bbf264" /> | <img width="618" height="114" alt="image" src="https://github.com/user-attachments/assets/0933c0c2-a669-4236-9148-a25226214ce6" /> |
| <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/ac1b8d91-44fa-4ce0-8ddb-beba271a2423" /> | <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/8676e9f9-074b-40e9-a75b-76561437c081" /> | 

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

Forward-Port-Of: odoo/odoo#263118
Forward-Port-Of: odoo/odoo#255543

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Forward-Port-Of: odoo/odoo#263200
Forward-Port-Of: odoo/odoo#261521

### Issue before this commit:
Sales taxes at 7% and 5% were incorrectly mapped to the same tax report  tags as the 18% sales taxes, causing them to be reported under the  'Taxable Goods/Services at 18%' line. In addition, the 7% and 5% report  lines displayed negative amounts instead of positive ones.

### Steps to reproduce the issue:
1. Install l10n_mt
2. Create invoices using 18%, 7%, 5% taxes
3. Go to Accounting > Reporting > Tax Report
4. See the amounts for Taxable Goods/Services at 18% is negative and  all the invoices are reported into the Taxable Goods/Services at 18%  even if the tax applied to the invoice is 5% or 7%

### Cause of the issue:
An automatic script (https://github.com/odoo/odoo/pull/225252)  missed to invert sign of formulas for the 7% and 5% lines, so their  values were displayed with the wrong sign. Moreover it is assigned to  the 7% and 5% Malta sales taxes the III.1_base  and III.1_tax tags, which belong to the 18% tax report line.

### Reason to introduce the fix:
The tag mapping must match the tax report structure so that 18%, 7%, and 5% sales taxes are reported in their respective lines. The report formulas for the 7% and 5% lines must also use the proper sign convention to display positive amounts consistently.

opw-6015509

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

Forward-Port-Of: odoo/odoo#263073
Forward-Port-Of: odoo/odoo#254894

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#263036
Forward-Port-Of: odoo/odoo#257293

Currently, when a res.parter is given a parent, base_address_extended runs _onchange_city_id. This sees the city change and alters the zipcode to match the city's zipcode. However, this field can be manually altered to differ from the city's zipcode. Thus, when a parent has a city, the zipcode will override the manually entered zipcode for a child contact.

This commit solves this by checking for the parent's zipcode before blindly setting it to the city's zipcode.

Steps to reproduce:

1. Install `base_address_extended`
2. Enable "Enforce Cities" on a country `(res.country)`
3. Add a city to that country with a zipcode of 123
4. Create a new contact (parent) and select the configured country
5. Select the city (the zipcode will fill in from the city's zipcode)
6. Overwrite the zipcode with 456
7. Save the contact (parent)
8. Create a new contact (child)
9. Set the company to the parent contact and save
10. The zipcode of the child will be the city's zip (123), not the parents' zip (456), thus the addresses will be different, and the child contact type will be 'other'

opw-6131280
closes #262651

Forward-Port-Of: odoo/odoo#262651

Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account

Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.

Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.

[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7

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

Forward-Port-Of: odoo/odoo#263246
Forward-Port-Of: odoo/odoo#260261

With Employee Login enabled in POS, leaving the “Basic rights” field empty is meant to allow all employees to log in as basic cashiers.

In v19, configuring at least one Advanced/Minimal employee while keeping “Basic rights” empty incorrectly restricted the login list to only the explicitly configured employees (and the linked backend user), so other employees could no longer sign in.

Steps to reproduce:
-------------------
* Go to POS settings and enable Employee Login.
* Add at least one employee in Advanced rights.
* Leave Basic rights empty.
* Open POS login.

> Observation:
Only Advanced can sign in.
Other employees are missing.

Why the fix:
------------
The employee loading domain must only become restrictive when Basic rights is explicitly set. If Basic rights is empty, all company employees should remain selectable, and Advanced/Minimal should only affect roles, not visibility. Align with 19.1 behavior/state of code.

opw-6170066

Forward-Port-Of: odoo/odoo#263100
Forward-Port-Of: odoo/odoo#261939

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#263036
Forward-Port-Of: odoo/odoo#257293

The session id rotates softly every 3 hours

For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie`
instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app.

Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens.

For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app.

This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads.

This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours.
The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation.

Forward-Port-Of: odoo/odoo#263325

### Steps to reproduce:
- Download 'Sign' and 'Contacts' apps
- Create a contact with a really long name
- Create a sign document template with a multiline text field (Read-only) that has contact name value
- Click 'Sign Now' and put the new contact as the signer
- Sign and download
> The text appears as a single extended line exceeding field/page boundaries

### Cause of Issue:
The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely.

### Fix:
Accounted for long texts that have spaces and long words to show all the information in the PDF

opw-6045062

Forward-Port-Of: odoo/enterprise#114813

**Steps to reproduce:**
Log in as admin and ensure notifications are handled in Odoo.
Enable push notifications and the 'Task Created' subtype for a project.
As a second user, create a new task in that project.

**Current behavior before PR:**
admin received escaped content in the push notification
(e.g., `A new task has been created in the "Project Name" project`)

**Cause:**
For inbox users, we send a client-side push notification using `previewText` as
the body. This field returns a markup object containing escaped characters,
which are converted to a string when passed to the notification body. Since the
notification body only accepts plain text, these characters are displayed
literally to the user.

**Desired behavior after PR is merged:**
admin receives the unescaped content in the push notification.
(e.g., `A new task has been created in the "Project Name" project`)

task-5112810

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

Forward-Port-Of: odoo/odoo#263187
Forward-Port-Of: odoo/odoo#240331

Purpose: The Brazilian Federal Government, through the Brazilian Federal Revenue Service (Receita Federal do Brasil), is implementing the alphanumeric CNPJ to address the imminent depletion of its capacity to generate new CNPJ numbers. The current, exclusively numeric model is approaching its limit. The transition to a format that includes letters and numbers expands the number of possible combinations, ensuring the future availability of registrations for new companies. With the government expanding the CNPJ numbers, we need to implement a solution to support the alphanumeric CNPJ that will be issued starting July 2026.

Current Behavior: The method, `is_valid,` from stdnum is currently used to determine whether the CNPJ is valid or not. This is now considered an outdated method to determine the validation.

Changed Behavior: The new validation logic by stdnum, found here https://github.com/arthurdejong/python-stdnum/commit/d3ec3bd7fefe0d0a708b6594a66de28777eb9b8d, is patched into `check_vat_br.` The reasoning for patching this rather than calling stdnum is because using stdnum will cause library dependency issues for older versions of Odoo.

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

Forward-Port-Of: odoo/odoo#262654
Forward-Port-Of: odoo/odoo#260516

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#115581

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804

Purpose
========
To enable video support in social stream posts.

Specification
==============
Videos can now be played directly from the Media Carousel Dialog.

Note: Twitter videos are currently unavailable and will redirect to the original post.

Technical
==========
- Rename the model 'social.stream.post.image' to 'social.stream.post.attachment'.
- Add the 'type' field to specify the content type.
- Add the 'thumbnail_url' field to specify thumbnail of video.
- Update all class names to reflect the changes.
- Rename the field 'stream_post_image_ids' to 'stream_post_attachment_ids'.
- Rename the field 'stream_post_image_urls' to 'stream_post_content_json'.
- The 'stream_post_content_json' field is now computed as a key-value pair containing
the content type, url and thumbnail url.
- Rename the component 'ImagesCarouselDialog' to 'MediaCarouselDialog'.
- Introduce an optional 'media_type' prop in MediaCarouselDialog to support redirection
for twitter video.

social_facebook:
- For single content, the API returns 'video_inline' and 'animated_image_video' for
video formats.
- For albums, the API returns 'video' for any video or GIF content.

social_instagram:
- The API specifies content types as either 'VIDEO' or 'IMAGE'.

social_linkedin:
- GIFs are received as image files.

social_twitter:
- The API provides only 'preview_image_url' for videos and GIFs, so we store post link in
content_url and preview_image in thumbnail.
- Clicking on a preview in the MediaCarouselDialog redirects to the Twitter post.

Task-3897765

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

Currently, generating the Swiss Master Data report raises an error

### **Steps to reproduce:**
1) Install `l10n_ch_hr_payroll` with demo data.
2) Switch to a Swiss company.
3) Navigate to `Payroll > Reporting > Master Data`. 
4) Create a new report and click Generate Data.

### **Error:**
IndentationError: expected an indented block after 'else' statement on line 116

### **Root Cause:**
The QWeb template had a conditional block using `t-elif` followed by an empty `t-else` at [1]. During template compilation, this generated a Python `else` statement without a body, leading to an IndentationError.

[1]- https://github.com/odoo/enterprise/blob/b77984b3a9fb1b35c07e152a0f86aaf4d430e2c0/l10n_ch_hr_payroll/report/l10n_ch_wage_type_report.xml#L44

### **Fix:**
This commit prevents the error by removing the empty `t-else` block and ensuring `category_ids` are properly evaluated by computing their codes and checking if they include `BASIC`, `ALW`, or `DED`.

**opw-6107565**

Forward-Port-Of: odoo/enterprise#113808

Issue:
----------------------------
In the maintenance request form view, the 'Block Workcenter' field was
displayed near the priority field in the top-right corner.

Steps to Reproduce:
----------------------------
- Install `mrp_maintenance` module.
- Open a maintenance request linked to a work center.
- Notice that the 'Block Workcenter' field appears beside the priority
  field in the top-right section.

Cause of the issue:
----------------------------
Following the UI changes introduced in [PR](https://github.com/odoo/odoo/pull/251761),
the position of the
priority field was updated. However, the inherited XPath used for the
'Block Workcenter' field was still targeting the priority field,
causing the field to be inserted at an incorrect position.

With this commit:
----------------------------
Update the XPath to match the new form view structure, ensuring that the
'Block Workcenter' field is displayed in the correct location and aligned
with the updated UI layout.

Forward-Port-Of: odoo/enterprise#116193

Steps to reproduce:
- Install `Accounting` module
- Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1
- Accounting > Review > Journal Audit > Expand Sales

Traceback: `KeyError: 'no_format'`

Cause:
This error occurs when we expand the lines. During the expansion, we [append] a `Load more...` pagination row inside the report lines. In that row, we pass empty [dictionaries] in
`columns`, like: `columns': [{}, {}, {}, {}, {}, {}]`. and we have offset. So, after expanding, there are two lines, and the second one is the Load more line. Because its [columns] contain empty dictionaries, the `no_format` key is not found, which results in a `KeyError`.

Solution:
We are passing a `None` value if `no_format` is not present in the line's columns.

[append]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5765
[dictionaries]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5867-L5878
[columns]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_journal_report.py#L158

opw-6125082

…roup

Steps to reproduce:
 - Set a low value for `prefix_groups_threshold` in account reports so that lines are grouped by prefix (e.g. in databases with large volumes, such as 6k+ lines).
 - Open a report (e.g. Trial Balance or General Ledger).
 - Unfold a prefix group.

Issue:
   ```python
 File "/home/odoo/src/enterprise/account_reports/models/account_report.py",
 line 5718, in get_expanded_lines_readonly
 return self.get_expanded_lines(options, line_dict_id, groupby,
  expand_function_name, progress, offset, horizontal_split_side)
 File "/home/odoo/src/enterprise/account_reports/models/account_report.py",
  line 5707, in get_expanded_lines
 lines = self.env[self.custom_handler_model_name]._custom_line_postprocessor
  (self, options, lines)
 File "/home/odoo/src/enterprise/account_reports/models/account_general_ledger.py
  ", line 354, in _custom_line_postprocessor
 if report._parse_line_id(lines[0]['id'])[-1] ==
     ('', 'account.report.line', report.line_ids[0].id):
 IndexError: list index out of range

```
Cause:
    Prefix groups are built based on the displayed line name, which includes
 the account code (e.g. "401000 Sales"). However, during unfold, the
 filter was applied on `account_id.name`.

 As a result, applying a prefix like '4%' on `account_id.name` (e.g. "Sales")
 returned no records, leading to empty results and the above crash.

 Additionally, prefix grouping could create invalid or meaningless groups
 when the extracted prefix character was non-alphanumeric (e.g. spaces or
 special characters).

Fix:
 - This patch updates the unfold filtering logic to use `account_id.code` when grouping by `account_id`, ensuring that the prefix filter is applied on the correct field.
 - Skip non-alphanumeric prefix keys during grouping to avoid generating irrelevant or invalid groups.

opw - 6106726
upg - 3985833

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

# How to reproduce
- Install the l10n_hu_edi module
- Switch to a Hungarian company
- Enable a currency (e.g., EUR) and configure two different exchange rates on two different dates
- Create a new invoice with :
	- Delivery Date: One of the configured date
	- A line with a price unit and a tax
- Save the invoice
- Edit the invoice :
	- Delivery Date : The other configured date
	- Change the price unit of the line
- Save the invoice

# The problem
The taxed amount total is using the old price unit

# Cause
## TLDR
This commit (https://github.com/odoo/odoo/pull/225407) made it so we recompute the tax when the currency is changed with round globally. This recomputation is based on the old tax values, so it should not be done when editing the base lines in the form view. To prevent this, a condition checks that the invoice date was not changed (which should be the only way to change the currency rate from that view if I understand correctly).

Sadly, the l10n_hu_edi module changes this behavior and makes it so the currency rate is also recomputed when the delivery date changes

## Detailed analysis

In the write() method of an account_move, we try to determine `round_from_tax_lines`. Before, in the situation where a base line is modified, it was computed here :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3032-L3049

In our use case, `round_from_tax_lines` would then equal to `False`

But, this commit (https://github.com/odoo/odoo/pull/225407) added the following condition that made it so in our use case, `round_from_tax_line` is trucy :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3029-L3031

That value is then used right after in the computation of the tax line values :

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3061

Since `round_from_tax_line` is trucy, we pass the tax_lines to the `_round_base_lines_tax_details()` function

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L1638

Which calls the `_round_tax_details_tax_amounts_from_tax_lines()` function. That function changes `base_lines["tax_details"]["tax_data"]` `tax_amount` and `tax_currency` based on the tax_lines `balance` and `amount_currency`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L2143-L2144

Except, those tax_lines values are the values of the current tax_lines, not the updated one. So they use the `balance` and `amount_currency` values of before the write

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L1631-L1632

`base_lines["tax_details"]["tax_data"]` is later used to define `tax_rep_data`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L2437-L2452

Which is then used to determine `base_lines_to_update`

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_tax.py#L3074-L3080

Nevertheless, this issue is quite niche because the condition to assign `round_from_tax_lines` checks that the invoice date has not changed, which would be the only way to edit the currency rate and the base lines at the same time

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/account/models/account_move.py#L3029

Except that the l10n_hu_edi module defines an override to recompute the currency rate when the delivery date changes

https://github.com/odoo/odoo/blob/262088c98673a342aa0ccdd70465e3be6bcb2439/addons/l10n_hu_edi/models/account_move.py#L128-L130

# Proposed solution
Since the tax recomputation is done using the values before the write, we never want to do it if the base lines have changed. Editing the condition of the commit that introduced the issue would not be enough because any module can ask for a currency rate recomputation for any reason.

Because of this, we should do the tax recomputation only if the base_lines have not changed.

opw-5800521

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