Currently, an error occurs when processing the payment of a return POS order whose original order has already been shipped.

**Steps to Reproduce:**
1. Install the stock and pos modules with demo data.
2. In config, activate the "**Allow Ship Later**" for _Furniture Shop_.
3. Open register and create an order with a Ship Later date.
4. Inventory > Delivery Orders > Validate the picking generated for that order.
5. Open original POS order (form), click "**Return Products**".
6. Open the returned order, click "**Payment**" and make the payment.

**Error:**
`ValueError - Expected singleton: pos.order(2, 1)`

**Cause:**
At [1], `reference_ids.pos_order_ids` is a many2many relation, but the logic assumes it contains only a single order. As a result, accessing `order.session_id.id` or `order.id` raises a singleton error when multiple related orders are present.

**Fix:**
This commit ensures that picking values are generated using a single pos order reference by selecting the relevant one from the multiple pos orders.

[1] - https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/point_of_sale/models/stock_picking.py#L157-L160

sentry- 7071798497

Forward-Port-Of: odoo/odoo#238467

…omposer

Problem:
In the "Activity" tab of the composer, adding a second file does not work. The first file is added correctly, but subsequent uploads are ignored.

Cause:
The selection is lost during file selection because the component is re-rendered, which recreates the DOM nodes.

This re-render only happens in `HtmlMailField` because it processes the value through `convert_inline`. Even when `lastValue` and `value` are logically the same in `useRecordObserver`, they differ in markup:

- `lastValue` contains self-closing `v:image` and `v:fill` tags.
- `value` contains open/closing versions of those tags because they are not excluded from the self-closing to open/closing conversion.

This mismatch triggers a re-render, causing the selection to be lost and preventing the second file from being inserted.

Solution:
Exclude `v:image` and `v:fill` from the self-closing to open/closing tag conversion so that `lastValue` and `value` remain equivalent. This prevents the unnecessary re-render and preserves the selection.

Steps to reproduce:
- Click on "Activity" in the chatter to open the dialog.
- Click in the "Log a note..." field.
- Use the upload button to add a file.
- Press Enter.
- Use the upload button again to add another file.
- Observe that the second file is not added.

task-5490722

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

Forward-Port-Of: odoo/odoo#245721

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/67a692f068 [REL] 19.1.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8f34d5715d [FIX] dom_helpers: wait for document ready [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/ce4efeedb2 [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/23bd59864c [FIX] regexextract : invalid regex throw error [Task: 5892417](https://www.odoo.com/odoo/2328/tasks/5892417)
https://github.com/odoo/o-spreadsheet/commit/1f06628b29 [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311)
https://github.com/odoo/o-spreadsheet/commit/5cc8a0c065 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007)
https://github.com/odoo/o-spreadsheet/commit/fd532281cd [FIX] menu: can open empty menu popover [Task: 5863077](https://www.odoo.com/odoo/2328/tasks/5863077)
https://github.com/odoo/o-spreadsheet/commit/379894f6bd [FIX] *: fix faulty css zoom  detection [Task: 5453400](https://www.odoo.com/odoo/2328/tasks/5453400)
https://github.com/odoo/o-spreadsheet/commit/bb484e3428 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

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>

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#244428

Steps to reproduce
------------------
1. Enable "Log in with Employees"
2. Add employee "A" to the "Basic rights" group.
3. Add employee "B" to the "Minimal rights" group.
4. Make sure to remove all other employees from these 2 groups!!
5. Now save and go back to the main settings page, remove employee "A" from "Basic rights" group, such that this group is now empty.
6. Save the changes.

Observation -> Employee "A" is still in the group "Basic rights"!!

Why the issue
-------------
When deleting records from an `x2many` field in pos, from the main settings page, we do not pass the associated `unlink` commands in the arguments of `web_save` when clicking "Save", we just pass an empty commands list `[]`, because the backend, specifically the method `_preprocess_x2many_vals_from_settings_view` will take care of unlinking all the records before applying the new commands. So passing an empty commands list when updating an `x2many` field will be equivalent to saying "Unlink all records for that field, then apply no commands", i.e. just unlink all records for that field.

However, after https://github.com/odoo/odoo/commit/1f45b035354bb9040be3aba3a79392e603e870b4, we now filter out updates having an empty commands list, and thus now trying to unlink all records of a `x2many` does not work, since an empty command list will be dropped from the updates, before reaching `_preprocess_x2many_vals_from_settings_view`.

The fix
-------
We add stricter filtering logic, to keep valid command lists, even when
they are empty.

opw-5725879

Forward-Port-Of: odoo/odoo#245261

**Problem:**
POS self-order confirmation emails (delivery and takeout) display the order amount without the currency symbol and proper formatting.

**Steps to reproduce:**
1. Create a POS self-order with delivery or takeout
2. Preview or send the confirmation email
3. Observe the amount displays without currency symbol or formatting

**Current behavior:**
Email shows amount as a plain number (e.g., "2.0") without currency symbol or locale-specific formatting.

**Expected behavior:**
Email should display amount with currency symbol and proper formatting based on user's locale (e.g., "2,00€", "$2.00", etc.).

**Cause of the issue:**
The email templates used direct field output `t-out="object.amount_total"` which renders only the numeric value without any formatting. This bypasses Odoo's standard currency formatting that handles both the symbol and locale-specific decimal/thousand separators.

**Fix:**
Use the `format_amount()` helper function which properly formats monetary values with currency symbols and locale-appropriate separators. The function takes the amount and currency as parameters and returns the fully formatted string respecting the user's language settings.

opw-5485801

Forward-Port-Of: odoo/odoo#244042

## Short functional explanation of the error
When duplicating a warehouse, if it has an PoS operation type,
this operation type will not be duplicated. On the other hand,
all other operation types will be duplicated. 

## Reproduction Steps
1. Make sure PoS and inventory are well installed.
2. Go to inventory. 
3. Click on configuration, then warehouse.
4. Select a warehouse, click on action, then duplicate.
5. Click on configuration, then on Operation Types.

### Expected behavior
We should be able to see 2 instances of PoS operation type:
one for the original company, and one for the copy.

### Unexpected behavior
There's only one instance of PoS operation type, which is
related to the original company.


## Origin of the issue
PoS operation type is a model inherited from stock.warehouse,
and no copy method was defined. Therefore, upon duplication,
the copy method of the original stock.warehouse was called,
leading to issues with the field created in the inherited
version.

__
opw-4991271

Forward-Port-Of: odoo/odoo#227635
Forward-Port-Of: odoo/odoo#222694

`Description of the issue this PR addresses:`
The Product Configurator dialog border radius was unintentionally affected by button styling. The dialog inherited its border radius from the $btn-border-radius variable, which is intended only for buttons and is customized in the design template.

`Current behavior before PR:`
- The Product Configurator dialog uses --modal-border-radius: #{$btn-border-radius};.
- $btn-border-radius is customized to make buttons fully rounded.
- Due to this linkage, the dialog border radius changes unintentionally.
- The issue is reproducible across multiple industries such as electronic_store, outdoor_activities, and team_sports_club.

`Desired behavior after PR is merged:`
- The Product Configurator dialog no longer depends on $btn-border-radius.
- Dialog border radius remains consistent and independent of button styling.
- Button border radius customization does not affect modal dialogs.
- Styling remains consistent across all affected industries.

Task ID: 5913300

Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed.

Problem 1: If ZATCA does not properly receive the invoice generated
from a POS order (wrong onboarding, wrong details on company, etc.)
the invoice printed from POS will not contain the QR code, even after
successfully resubmitting the invoice to ZATCA, load the order and 
reprint the invoice to see this

Testing the fix: Change the VAT number on the company to be faulty, 
create a POS order, Fix the VAT number and resubmit the invoice, load
the POS order and reprint invoice, it will now show the QR code.

Problem 2: When disabling the E-invoicing for a phase 2 journal,
the POS receipt will still try to print the phase 2 QR code but the system
will flag it as 'not legal' leaving the POS receipt empty, when it should
instead print the phase 1 QR code

Testing the fix: On the journal, disable the E-invoicing, and create a POS
order, it will now show the phase 1 QR code on the receipt

task-5032474

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

Forward-Port-Of: odoo/odoo#246932
Forward-Port-Of: odoo/odoo#234945

Steps to reproduce:
1. Open the Expenses app and navigate to 'Expenses to Process'.
2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears.
3. Remove filters.
4. The layout becomes 'disturbed'—the upload overlay misaligns and  overlaps the dashboard.

Issue:
The issue occurred because the SCSS selector was incorrectly targeting the combination of .hr_expense and .o_list_view. In the Odoo DOM structure, the hr_expense class is added to the Renderer via XML, while o_list_view is assigned to the main Controller. Because the selector never matched an actual element, the min-height: 100% rule remained inactive.

Without a stable minimum height, the Renderer container collapses when empty. This prevents the 'Pink Overlay' from having a stable anchor point, leading to layout shifts and visual interference with the Search Panel and Dashboard headers.

Solution:
Update the SCSS selector to target &.o_list_renderer and &.o_kanban_renderer. This ensures the rule correctly matches the element carrying the hr_expense class. By forcing a min-height: 100% !important on the renderer itself, the container remains stable regardless of the data count. This provides a consistent workspace for the 'No Content' helper to render without disrupting the surrounding flexbox layout.

opw-5452618

Forward-Port-Of: odoo/odoo#247366

- Cash machine UI in the POS has been cleaned up
  - Reset button and Download logs button have been moved to the
    backend.
  - Warnings about low cash now take up less space.
  - The cash inserted amount is now shown inside the payment line status
    box.
- Shortcut to the Glory admin page has been added to the payment method
  form.
- Error detail text is now shown when provided by the cash machine.
- Bugfixes
  - There should no longer be multiple disconnected popups appear if the
    tab is left inactive for a while.
  - The session/occupy settings of the connected Glory machine are now
    respected, this reduces the number of requests sent when they are
    not enabled.
- Some tests have been added for the Glory service.

In order to add Glory functionality in the backend, the Glory service was split into two components. The `glory_service.js` file handles all the communication with the Glory machine, but it doesn't handle the POS integration at all. The POS side is now handled by `payment_glory.js`. This means that in the backend we can still use `glory_service.js` to interact with the machine without being in the POS.

task-5891688

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

Forward-Port-Of: odoo/odoo#246986

Steps to reproduce:
1. Open the Expenses app and navigate to 'Expenses to Process'.
2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears.
3. Remove filters.
4. The layout becomes 'disturbed'—the upload overlay misaligns and  overlaps the dashboard.

Issue:
The issue occurred because the SCSS selector was incorrectly targeting the combination of .hr_expense and .o_list_view. In the Odoo DOM structure, the hr_expense class is added to the Renderer via XML, while o_list_view is assigned to the main Controller. Because the selector never matched an actual element, the min-height: 100% rule remained inactive.

Without a stable minimum height, the Renderer container collapses when empty. This prevents the 'Pink Overlay' from having a stable anchor point, leading to layout shifts and visual interference with the Search Panel and Dashboard headers.

Solution:
Update the SCSS selector to target &.o_list_renderer and &.o_kanban_renderer. This ensures the rule correctly matches the element carrying the hr_expense class. By forcing a min-height: 100% !important on the renderer itself, the container remains stable regardless of the data count. This provides a consistent workspace for the 'No Content' helper to render without disrupting the surrounding flexbox layout.

opw-5452618

**Steps to reproduce:**
- Go to the current user preferences
- Go to its signature field
- The current state should be something like:
```
--
Mitchell Admin
```
- Apply bold formatting on the text
- Save the changes
- Refresh
- Remove the bold formatting
- Press enter between the two lines (at the end of `--`)
- Save the changes
- Go to the Contact app
- Select any record
- Go to its chatter
- Click on `Send Message` and then the `Full Composer` expand button
- Send the mail
- In the chatter multiple `Read More` are added for the same signature

(I think it can appears in multiple operations,
this is just an example related to the `<strong>`
element becoming `<span>` on removal)

**Issue:**
Playing with the html editor on the signature field can break the `tag_quote` flow due to the added elements.

**Fix:**
Explicitly add `"data-o-mail-quote"` to the signature container which is added when opening the `fullComposer`.
It could also be an issue related to the html_editor but this seems cleaner to fix it here.

This issue was fixed in 19.0 in a similar way by adding a common div around the signature and adding the same attribute.

related: https://github.com/odoo/odoo/commit/6eb55c42158b08652c4c533bf56b5333c162bd3a

opw-5149505

Forward-Port-Of: odoo/odoo#246982
Forward-Port-Of: odoo/odoo#231954

**Issue**
In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities.

**Steps to reproduce**
- Create a subcontracting BOM of a final product using 1 component product
- Create a PO of the final product for a quantity of 10 and confirm it
- Modify the BOM to use 2 component products instead
- Go to the receipt of the PO and modify the quantity to 2 and validate it
- Click on the move line of the receipt -> The displayed quantity is 10 instead of 2

**Cause**
Setting the quantity triggers this line:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 
which calls:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107

Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89

And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146

**Solution**
Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies.

opw-5493577

Forward-Port-Of: odoo/odoo#246433
Forward-Port-Of: odoo/odoo#245065

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/a906c68b8e [REL] 18.3.35 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7d959d419d [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311)
https://github.com/odoo/o-spreadsheet/commit/addf98c28c [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/17e5af05f7 [FIX] tests: fix network serialization in mock [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/630faa62a2 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007)
https://github.com/odoo/o-spreadsheet/commit/e5af7c65d3 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

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>

Steps to reproduce:
-------------------
1. Install `l10n_in` and `l10n_in_hr_holidays`
2. Switch to an Indian company
3. Create a user and related employee without Time Off rights
4. Log in with the new user and create a past time off
5. Approve the time off as an time off manager/admin
6. Open the validated time off record as the employee

Issue:
------
Opening a validated time off raises the following UserError:
 ```python
You must have manager rights to modify/validate a time off that already begun.
```

Cause:
------
The `_get_durations` method in `l10n_in_hr_holidays` was updating the
`l10n_in_contains_sandwich_leaves` field every time it was executed.

When a user opened a validated time off record, this triggered a `write()` operation. Since non-manager users are not allowed to write on already started validated leaves, this caused a [UserError](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/hr_holidays/models/hr_leave.py#L793-L798)

The field `l10n_in_contains_sandwich_leaves` does not need to be updated
when `l10n_in_is_sandwich_leave` is False.
See [[1]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L156-L157) & [[2]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L62)

And this [part of the code](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L160-L173) is responsible to update `l10n_in_contains_sandwich_leaves` value.

**NOTE:**
Opening future validated time off records as a non-manager user triggers
`AccessError` as it is not allowed to update the validated time off record.

Solution:
---------
Ensure that `l10n_in_contains_sandwich_leaves` is updated
only when `indian_leaves` is applicable.

opw-5373055





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

Forward-Port-Of: odoo/odoo#240056

Issue:
-------
When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor.
for ex: `#snippet-anchor` in the `Button URL` field in the settings.

Cause:
--------
This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place.

Solution:
------------
To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on.
This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside.

Steps to reproduce:
-----------------------
1. Create a db in version 18.3 with website_sale installed.
2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings.
3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button.
4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings.
5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet.

Ref PR:
----------
https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399

Attachments:
-----------------
**Before Fix:**
[vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0)


**After Fix**:
[vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5)


- OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517)

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

Before this commit: safari returns invalid document in collaboration, typically when a chrome user is sending history steps with undo. Reproduction steps:
1. In chrome, use an existing task with empty description or create a task in the project (first create the task title in the kanban view, then click edit), enter 4 lines of text
2. In one of the middle lines, delete one character --> undo --> add a new character
3. Save the task, open the task in Safari incognito, log in as demo (not admin), go to the task and click the description field
4. TraceBack: IndexSizeError: The index is not in the allowed range.

After this commit: we use the range of the DOM selection to set the
offsets of activeSelection. If the DOM selection is too wrong to be
corrected, e.g. the selection's anchor node isn't the same with range's
start container (or end container if direction is right to left), we do
not set new activeSelection but just return the previous activeSelection

task-5428788


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

Forward-Port-Of: odoo/odoo#246056

When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated.

### Steps to reproduce:

* Create a product A with variants of type never
* Create a sales order with two product A and confirm it
* Go on the delivery (don't validate it) and create a delivery slip
-> Issue, the name of the product appears twice.
* Reduce the quantity of product delivered to one
* Confirm and create a backorder
* Print the deliveryslip
-> Issue, the name of the product appears twice in the backorder section

### Observation:

When confirming the SO:
It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant:
https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300
This information is added to the picking_description (for which the fallback value is the product name):
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340
When printing the delivery_slip, it uses description_picking (and attempts to filter out the name):
https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74
However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name.

The same issue is present here :
https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180

opw-5153222

Forward-Port-Of: odoo/odoo#239693

### [IMP] databases: remove xmlrpc fallback for odoo.com

Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version.

In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`.

In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code.

The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page.

### [FIX] databases: disable the KPI-selection wizard

With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field.
Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view.

The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2).

Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314)

### [FIX] databases: handle fetch errors better

With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user.

### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously

Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action.

With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action.

Forward-Port-Of: odoo/enterprise#105965
Forward-Port-Of: odoo/enterprise#105176

The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured.

https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151

Steps To Reproduce:
1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped".
2. Go to Accounting Dashboard and create a new Miscellaneous Operation.
3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries).
4. Try to post the entry.
5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..."

The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types.

Commit that caused the issue:
https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b

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

Forward-Port-Of: odoo/enterprise#104476

For old databases that were created before 16.0, existing sign request might not have a communication company set.

Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:

```
Traceback:
  ...
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
    context = self.get_document_qweb_context(request_id, token)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
    date_format = posix_to_ldml(lang.date_format, locale=locale)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
    for c in fmt:
TypeError: 'bool' object is not iterable
```

This commit fallback to the create user's company to determine the date language when there is not communication company set.

no-task (from feedback pad)

Forward-Port-Of: odoo/enterprise#87526

Description of the issue/feature this PR addresses:
  In a multi-company environment, confirming a Purchase Agreement (Blanket Order) automatically generates Vendor Pricelist (product.supplierinfo) entries for the linked
  products. Currently, these entries default to the user's current active company rather than the company specified on the Purchase Agreement. This leads to data
  inconsistency where pricelists are visible and owned by the wrong company.


  Current behavior before PR:
  When a Blanket Order belonging to Company A is confirmed by a user who has Company B as their current active company, the resulting Vendor Pricelist record is
  assigned to Company B. This is because the company_id is not explicitly passed during the creation of the product.supplierinfo record, causing it to fall back to the
  environment default.


  Desired behavior after PR is merged:
  The Vendor Pricelist record will explicitly use the company_id from the Purchase Agreement it originated from. This ensures that the pricelist is correctly assigned
  to the agreement's company rather than from the active company

related to ticket i made #5909892

When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated.

### Steps to reproduce:

* Create a product A with variants of type never
* Create a sales order with two product A and confirm it
* Go on the delivery (don't validate it) and create a delivery slip
-> Issue, the name of the product appears twice.
* Reduce the quantity of product delivered to one
* Confirm and create a backorder
* Print the deliveryslip
-> Issue, the name of the product appears twice in the backorder section

### Observation:

When confirming the SO:
It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant:
https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300
This information is added to the picking_description (for which the fallback value is the product name):
https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340
When printing the delivery_slip, it uses description_picking (and attempts to filter out the name):
https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74
However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name.

The same issue is present here :
https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180

opw-5153222

**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).

Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration

**Cause**
The fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 will result
in a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51

**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/d58ecdccb89401751c8ee056c4166427ea005f5e
was to correct an issue related to the computation of some `project.task`
fields calling resource methods, we can instead go for a safer solution
in `project` which doesn't affect `resource`/`hr` modules.

Code below the search already ensures that leaves are only applied
when their company matches the resource's company:
https://github.com/odoo/odoo/blob/fdd9edb6a4ef3aa18449be537c954a06b32578e3/addons/resource/models/resource_calendar.py#L409-L410
When `_leave_intervals_batch` is called without resources, existing code
adds a company domain (see `_get_unusual_days` for example).

opw-5496999
opw-5401425

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4587c34166 [REL] 18.0.56 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/83a2147ebf [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311)
https://github.com/odoo/o-spreadsheet/commit/03ebb687fa [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/d953505355 [FIX] tests: fix network serialization in mock [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/2f4cf70fc1 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007)
https://github.com/odoo/o-spreadsheet/commit/0dcc3ce629 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

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>

### Issue:
When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0

### Cause:
In `export_boe()`, the `report_lines` were get based on the `section_report` options
However, `section_reports` do not store the date
or return periodicity of the selected report
As a result, using their options always fetched data for the current period instead of the specified year

### Note:
`_generate_mod_390_page2()` also had issues:
some lines were missing or incorrectly indexed

The mod 360 format, it strict in the structure with specific index so it may produce invalid documents

The latest documentation for mod 390:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` and switch to ES Company
- Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025)
- Open Tax Return, switch to Mod 390, and set year to 2025
- You should see data in the 2 first sections
- Use the gear icon, and download the BOE
- Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report

opw-5457374

Forward-Port-Of: odoo/enterprise#104928

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/5a46aed424 [REL] 17.0.86 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/045e5c6457 [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/96220f7707 [FIX] tests: fix network serialization in mock [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921)
https://github.com/odoo/o-spreadsheet/commit/2ed5b7ce4b [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753)

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>

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons:

1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date.
2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report.

Additional fixes and improvements:

- Correctly map columns 18 to 26 in Report 13.1:
  - 18–20: Incoming movements
  - 21–23: Outgoing movements
  - 24–26: Final balance
- Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost.
- Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation.
- Extend test coverage to include cases where the report includes opening balances due to past transactions.
- **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements.
- **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type:
  - `25` for incoming reversals
  - `24` for outgoing reversals
- Force operation type `99` for all `A1` lines, as required by the report.
- Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo.