Currently, when applying a `Group By` filter in `list views`, the record count 
is displayed far from the group label.

**Steps to reproduce:**
- Open `Apps` and switch to the list view.
- Apply a `Group By` filter (e.g., Author).
- Observe where the grouped record count is displayed.

**Observation:**
The total number of records is rendered under unrelated columns rather than 
being displayed next to the group label.

**Root Cause:**
After commit [1], the `ms-auto` class at [2] causes the `group count` to be 
moved away from the group label.

**Fix:**
This commit ensures that the grouped record count is displayed next to the 
group label, consistent with previous versions.

**Before:**
<img width="1909" height="466" alt="5438766_before" src="https://github.com/user-attachments/assets/3ac44b19-2dad-4f01-ab78-8f456405e4d5" />

**After:**
<img width="1905" height="453" alt="5438766_after" src="https://github.com/user-attachments/assets/ce0143e5-feeb-49ee-8d42-5235add669e4" />

[1]:
https://github.com/odoo/odoo/pull/235250/commits/963696f4839b3043226ac118bf6a4ae8e8e92823

[2]:
https://github.com/odoo/odoo/blob/25c372b254cec8635bb73b04c7729530f8a08e72/addons/web/static/src/views/list/list_renderer.xml#L247

opw-5438766

The daily demand in forecasting does not take into consideration the product that are used for production.

Steps to reproduce:
-------------------
* Install stock and mrp
* Create a tracked Product "Component" with RR
* Add some "on hand quantity" 
* Create Product "Product" with a BOM that use "Component"
* Create a manufacturing order for "Product" and confirm it
* Go back on the RR of "Component" and use "resplenishment information" button (small i) 
-> Daily demand does not reflect the "Component" used for manufacturing.

Observation:
-------------
When Opening the resplenishment information, the daily_demand is calculated: https://github.com/odoo/odoo/blob/c38346ccc3e44670b76bfb010795bdfa7004b532/addons/stock/wizard/stock_replenishment_info.py#L177 For that calculation quantity_out is used, obtained just before: https://github.com/odoo/odoo/blob/c38346ccc3e44670b76bfb010795bdfa7004b532/addons/stock/wizard/stock_replenishment_info.py#L164-L167 Since it only consider moves that goes directly to the client, it will not take into consideration products that are used for production.

opw-5497584

Forward-Port-Of: odoo/odoo#246125

**Issue Description :**

In _mail_group_by_operation_for_mail_message_operation [function](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/addons/mail/models/models.py#L77).
The memory error occurred due to recordset concatenation triggered by: [operation_documents[record_operation] += record](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/addons/mail/models/models.py#L83)
This resulted in repeated recordset concatenations inside a loop. Since recordsets are immutable, each concatenation [creates a new recordset](https://github.com/odoo/odoo/blob/a1f4c98ec025cb36b218072f5557c93d5f329929/odoo/orm/models.py#L5874) and reallocates the underlying tuple of IDs. When processing a large number of records this caused memory growth.

**Solution:**

Replace iterative recordset concatenation.

- Collect record IDs using Python sets (O(1) insertion).
- Build recordsets once per operation after the loop.
- Apply with_prefetch() only once per operation.

**Traceback:**
```
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py",
   line 397, in _search
    allowed_ids.update(self._find_allowed_doc_ids(model_ids))
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py",
   line 428, in _find_allowed_doc_ids
    operation_res_ids =
    records_all._mail_group_by_operation_for_mail_message_operation('read')
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/models.py", line 83,
   in _mail_group_by_operation_for_mail_message_operation
    operation_documents[record_operation] += record
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5851, in
   __add__
    return self.concat(other)
           ^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5864, in concat
    ids.extend(arg._ids)
 MemoryError
```

opw-[5915534]
upg-[3878714]
tgb - 2445
Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

*: website_sale

Since commit [1], the position of the arrows in the product snippet was broken when they were set to appear at the bottom.
It also fixes the arrow positioning when the snippet is set to full width, with the title displayed on the side and "Scrolling Mode" set to "All."
This commit correctly adjusts the arrow positioning.

[1]: https://github.com/odoo/odoo/commit/54fde5da6c229a7173c5b4c042b3330598db3904

task-5935743

| Before | After |
|--------|--------|
| <img width="1617" height="635" alt="Capture d’écran 2026-02-13 à 09 40 36" src="https://github.com/user-attachments/assets/21e3545c-e243-4ee7-9fd5-51ca06b8c496" /> | <img width="1620" height="664" alt="Capture d’écran 2026-02-13 à 09 39 14" src="https://github.com/user-attachments/assets/6dcdfc0f-6dc8-4293-9d23-ea36d19fc2b4" /> |
| <img width="1921" height="719" alt="Capture d’écran 2026-02-13 à 11 12 22" src="https://github.com/user-attachments/assets/8916438c-8108-43ec-a70a-aba8c83ba881" /> | <img width="1918" height="654" alt="Capture d’écran 2026-02-13 à 11 17 21" src="https://github.com/user-attachments/assets/df872f4a-5674-4fff-a0de-b6c99f30acb2" /> |



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

**Description of the issue:**

- When a user changes the language of a syntax-highlighted code block, the editor loses focus from the code input. As a result, the user must manually click back into the code block to continue typing

**Steps to reproduce:**
- Insert a syntax-highlighted code block.
- Click the language dropdown to change the syntax highlighting language.
- Select a different language from the dropdown.

The language dropdown closes correctly after selection. Focus does not return to the code block input. Instead, focus remains on the dropdown button.

**Cause:**
- Although focus is explicitly set back to the code block input after selecting a language, closing the dropdown restores focus to the element that was active when the dropdown was opened . As a result, the input does not receive focus.

**Solution:**
- For the language selector dropdown, set focusToggleOnClosed = false so that closing the dropdown does not restore focus to the dropdown button.
- For the copy button, prevent focus on pointerdown.

task-5785595

Forward-Port-Of: odoo/odoo#245161

Scenario:

- have two languages on website
- drop a snippet on a page in main language
- go to secondary language => you see the previous page version, and a
  notification with `Click on "Edit/Translate" to apply changes made on
  default language.` is shown
- click on Edit: Translate => you see the version with the change from
  main language applied
- save without doing a change

Result: nothing is saved

Expectation: delayed translations that we are seeing when editing
translation should be saved.

Cause:

Delayed translation (draft version from change of main language) on
website were added or disabled with:

- 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added
  the delay translation feature
- 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0
  disabled the feature
- 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0
  enabled the feature again

Currently delayed translations are only updated if there is a part of
that translation that has been edited and is dirty.

Fix: when we save translations, we should also save o_delay_translation
that are not dirty. These translations if there is a delayed translation
will publish the delayed translation.

opw-5187670
opw-5240423
opw-5250497
opw-5254832
opw-5344412
opw-5347408
opw-5419427
opw-5424761
opw-5892371

Forward-Port-Of: odoo/odoo#238696

When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error.

Steps to reproduce:
-------------------
* Install sales, inventory, subscription,
* Create a subscription product
* Create and validate a sale order with this product and a recurring plan
* Connect to Odoo with an user that only has inventory user right
* Validate the delivery -> Access Error

Observation:
-------------
When we validate the delivery,we call button_validate that will call [_action_done](https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_picking.py#L1427) 
During this we try retrieve invoices information [here](https://github.com/odoo/enterprise/commit/b07b1c47c97bb6d6da9fa61dacb5cba66aff2a16#diff-dbf7b40a6942fbcc81ebc4c3009a8a37a5a620cffac74889bd0ff2bccd52b1e3R30-R36).
The issue is that this user doesn't have access right to several records: 
* sol.order_id.invoice_ids  -> sale.order.invoice_ids 
* sol.order_id.last_invoice_date -> sale.subscription.plan

opw-5869446

Forward-Port-Of: odoo/enterprise#106623

Currently, an error occurs when user edits a reconciled line.

**Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):**

 - Install the `Accounting` module.
 - Create an `invoice` with an `invoice line` having an amount greater than zero.
 - `Confirm` the invoice.
 - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice.
 - Click `Reconcile` on that `statement line` and select the newly `created invoice line`.
 - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save.

`UnboundLocalError: local variable 'original_base_lines' referenced before assignment`

The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2].

This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error.

[1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394

[2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411

sentry-7189027839

Forward-Port-Of: odoo/enterprise#104432

Steps to produce:
---
- Install `sale_renting` and `contacts` modules.
- Go to contact and open `yourcompany` record.
- Add a new contact of type Delivery and save (leave the name empty).
- Go to Rental > New Order.
- Select YourCompany, Delivery as the customer.
- Add a rental product and confirm the order.
- Open the Schedule view.

Traceback:
---
`TypeError: sequence item 0: expected str instance, bool found`.

Root cause:
---
- At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence.

Solution:
---
- Use the partner's `display_name` instead of `name`. The `name` field
  can be `False` in some cases. The `display_name` field is a computed
  field that always provides a valid, formatted string by using fallback
  values such as the company name, parent name, or contact type. This
  ensures consistency and prevents errors

[1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61

opw-5914084
---

Forward-Port-Of: odoo/enterprise#106827

Since [1], the voip calls infinite scrolling does not work anymore.

Steps to reproduce:
- Make sure to have at least 14 recent calls
- Open the softphone
- Go to the recent/history tab
- Scroll to the end => You are stuck seeing only the 13 last calls.

This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration.

This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item.

Note that [1] disabled a test that was testing the feature. This commit of course re-enables it.

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd

Forward-Port-Of: odoo/enterprise#106658

Currently, an error occurs when user edits a reconciled line.

**Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):**

 - Install the `Accounting` module.
 - Create an `invoice` with an `invoice line` having an amount greater than zero.
 - `Confirm` the invoice.
 - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice.
 - Click `Reconcile` on that `statement line` and select the newly `created invoice line`.
 - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save.

`UnboundLocalError: local variable 'original_base_lines' referenced before assignment`

The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2].

This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error.

[1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394

[2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411

sentry-7189027839

Forward-Port-Of: odoo/enterprise#104432

Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values.

This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state).

This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period.

The following rules/fields are updated to use the version object:
- Tax Treatment Category
- Additional Withholding Amount
- Extra Pay
- TFN Declaration
- Medicare (Reduction, Exemption, and Levy)
- Training Loans
- NAT 3093 Amount (Tax Offset)
- Child Support (Garnishee and Deduction)

A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates.

Task-5002697

Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
    - weight: 10 kg
- Create a delivery picking:
    - Add one unit of P1
    - Mark as “To Do”
    - Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0

Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
    - `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
    - `pack.shipping_weight` is 0 on creation.
    - The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13

opw-5357843

Forward-Port-Of: odoo/odoo#245223
Forward-Port-Of: odoo/odoo#238917

__
Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 
__
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

Nothing happens

When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546

The company isn't taken into account in the domain, applying the holiday for every company.
 __
opw-5222883

Forward-Port-Of: odoo/odoo#246994

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248318
Forward-Port-Of: odoo/odoo#236276

Issue before this commit:
=========================
When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")`
in the `Number of SN` field of the Generate Serials/Lots wizard, 
a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`.

Steps to Reproduce:
=========================
- Install the "stock" module.
- Create a receipt for a serial-tracked product.
- Open the detailed operations.
- Click on "Generate Serials/Lots".
- Enter a string value in the "Number of SN" field.

Result: A traceback is raised with:
InvalidNumberError: `"dhha" is not a correct number.`

Cause of the issue:
=========================
The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) 
field is defined as type="text", which allows users to enter string values, 
even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), 
which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139).

With This Commit:
=========================
The input type is changed from type="text" to type="number", ensuring that 
only numeric values can be entered. This prevents invalid input and avoids the 
traceback when generating serial or lot numbers.
Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`,
ensuring that only integer values are allowed.

Forward-Port-Of: odoo/odoo#248529
Forward-Port-Of: odoo/odoo#248221

The aim of this commit is to prevent a csv import to timeout by applying the `limit_time` parameter for real.
We also added the `company_id` parameter to the caller to maximize the chances of processing the lines of the statement being imported first.

Context:
1) `_cron_try_auto_reconcile_statement_lines` was modified a few times in
   the last months with the bank reco widget revamping, the perf issues,
   etc.

   During that revamp, the timing limitation was made irrelevant if a
   `batch_size` wasn't provided.

   While it makes sense that the time limitation is irrelevant without a
   batch, not raising an error resulted in the client code letting the
   caller think the time limitation will be applied.
   Instead, we could provide a default batch_size.

2) The `company_id` parameter wasn't set which combined with no
   batch_size results in trying to reconcile the entire accounting
   from every company to which the user has access.

Before this commit:
- The limit_time parameter is ignored if the `batch_size` parameter isn't provided processing everything in the current transaction.
- The company_id parameter wasn't set resulting in trying to reconcile the whole accounting from all accessible companies in the current transaction.

After this commit:
- We provide a default `batch_size` of 100 and thus we really apply the timing
- We provide the `company_id` parameter to limit the reconciliation to the company of the statement.

opw-4890008

This commit is a backport of https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823 and https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424.

## Issue
When renewing a subscription, the tags and followers are not copied from the original subscription to the new one.

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a confirm a subscription S
    - Any *Customer*
    - Any *Recurring Plan*
    - Any Product
    - In the *Other Info* tab, add a tag T
3. There should be two followers on the subscription S: the creator of the subscription, and the customer. If it is not the case, add at least one follower.
3. Create and confirm an invoice for subscription S
4. Back on the subscription S, click *Renew*
5. **The tag T is missing on the new subscription. Also, the followers were not copied from subscription S.**

## Cause & Fix

### Tags
In `SaleOrder._prepare_upsell_renew_order_values`, tags are not part of the `values` generated when renewing a subscription:

https://github.com/odoo/enterprise/blob/a650fb74fd79965a6f0e441e61d8977c599057e6/sale_subscription/models/sale_order.py#L1149-L1171

They were added by https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823:

https://github.com/odoo/enterprise/blob/245759ef82250a8eb32f38853e5c5f6aac841823/sale_subscription/models/sale_order.py#L1173-L1175

### Followers
Similarly to the tags, followers were not added/subscribed to the subscription when generating the renewed subscription. This was fixed by https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424, by creating and calling the `_subscribe_followers_to_new_order(order)` after creating the new subscription (`order`):

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L956-L958

https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L2147-L2157

opw-5478071

Forward-Port-Of: odoo/enterprise#107230

When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error.

Steps to reproduce:
-------------------
* Install sales, inventory, subscription,
* Create a subscription product
* Create and validate a sale order with this product and a recurring plan
* Connect to Odoo with an user that only has inventory user right
* Validate the delivery -> Access Error

Observation:
-------------
When we validate the delivery,we call button_validate that will call [_action_done](https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_picking.py#L1427) 
During this we try retrieve invoices information [here](https://github.com/odoo/enterprise/commit/b07b1c47c97bb6d6da9fa61dacb5cba66aff2a16#diff-dbf7b40a6942fbcc81ebc4c3009a8a37a5a620cffac74889bd0ff2bccd52b1e3R30-R36).
The issue is that this user doesn't have access right to several records: 
* sol.order_id.invoice_ids  -> sale.order.invoice_ids 
* sol.order_id.last_invoice_date -> sale.subscription.plan

opw-5869446

Forward-Port-Of: odoo/enterprise#106623

Currently, an error occurs when user edits a reconciled line.

**Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):**

 - Install the `Accounting` module.
 - Create an `invoice` with an `invoice line` having an amount greater than zero.
 - `Confirm` the invoice.
 - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice.
 - Click `Reconcile` on that `statement line` and select the newly `created invoice line`.
 - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save.

`UnboundLocalError: local variable 'original_base_lines' referenced before assignment`

The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2].

This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error.

[1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394

[2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411

sentry-7189027839

Forward-Port-Of: odoo/enterprise#104432

Currently, an error occurs when user tries to generate lots on a picking receipt for a product that is tracked by lots.

Steps to replicate:
- Install `stock` and create a product `test` tracked `by lots`.
- Open Inventory > Operation > Receipts , create a new one with product `test` and quantity 3.
- Open the form view of the stock move for `test` using the `view` button.
- Click `Generate Serials/Lots` and type `a` in `Quantity received` and click generate. (Error-1 will occur.)
- Click `Generate Serials/Lots` and type `a` in `Quantity per lot` and click generate. (Error-2 will occur.)

Error-1 :
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1055, in generate_lot_qty
    line_count = int(quantity // qty_per_lot)
                     ~~~~~~~~~^^~~~~~~~~~~~~
TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'
```

Error-2 :
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1053, in generate_lot_qty
    if qty_per_lot <= 0:
       ^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'NoneType' and 'int'
```

Cause:
- As the user typed in alphabets the [parsefloat] returns `NaN` which will be translated to `None` python side.
- As quantity is received as None the [line1] raises Error-1.
- As qty_per_lot is recieved as None the [line2] raises Error-2.

Solution:
- Raised Usererror when quantity received or quantity per lot is either negative or not a number.

[parsefloat]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/static/src/widgets/generate_serial.js#L50-L51

[line1]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/models/stock_move.py#L1001

[line2]: https://github.com/odoo/odoo/blob/2da791df55762ae4dc1c06d2a43fad25b09dc11b/addons/stock/models/stock_move.py#L999


related-sentry-7254849206

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

**Description of the issue:**                                                                                                                                                                     
  _get_cart_and_free_qty duplicates inline the same logic already provided by _get_product_available_qty, bypassing the intended extension point.                                               
                                                                                                                                                                                                
**Current behavior:**
  _all_product_available delegates to _get_product_available_qty, but _get_cart_and_free_qty calls free_qty directly, causing inconsistent stock availability results within the same cart flow.
                                                                                                                                                                                                
**Desired behavior:**                                                                                                                                                                             
  _get_cart_and_free_qty delegates to _get_product_available_qty, making it the single extension point for all stock availability queries in the cart.

@tecnativa TT60862
@carlosdauden @pedrobaeza 


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

Selling a kit product (phantom BOM) that was tracked by lots in the Point of Sale incorrectly opened the lot/serial popup for the kit line. Only the kit's components should drive stock moves and lots; the kit product itself must not require a lot on the order line.

Steps to reproduce:
-------------------
* Create a product "Kit" with tracking = By Lots.
* Create a phantom BOM (type Kit) for that product with a component that is also tracked by lots; add stock and a lot for the component.
* Open a POS session and add the kit product to the order.

> Observation:
The Lot/Serial Number(s) Required popup appears for the kit product. After payment, stock moves are correctly created for the components (and their lots), so the popup on the kit line is wrong.

Why the fix:
------------
POS was using product.tracking only when deciding to show the lot popup, and did not treat phantom-kit products differently. With pos_mrp, stock moves for a kit line come from the BOM components, not from the kit product, so the frontend must not ask for a lot on the kit line. We add a computed flag pos_has_phantom_bom on product.product in pos_mrp and make isTracked() return false when that flag is set so the lot popup is skipped for kit products.

opw-5917964

### Issue:
Applying multi gift card from the same program results in an infinite reload cycle.

#### Steps to reproduce:
1- Create a gift card program and generate two gift cards.
2- In eCommerce add a deliverable product to cart.
3- Open cart and add both gift card codes.
4- Click on checkout to navigate to delivery step.

The page is going to keep refreshing.

### Cause:
The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.:
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24

After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line.

However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card

### Fix:
This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines.

Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card).

opw-5485912

Issue
-----
When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered".

Steps to reproduce
-----
- Create a UPS delivery
- Multiple packages
- Validate transfer
- Return
- Validate IN
- Return again
- Add the UPS under the "additional info" tab
- Ensure still multiple packages
- Validate OUT

Cause
-----
When preparing the shipping data, we go through

https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121

which leads us to do

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155

so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`.

https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58

From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns.

-----
Ticket:
opw-5866100

### Issue:

Cannot get passed the address form in `ar` localization.

#### Steps to reproduce:
1- Set up a company with Argentinian localization.
2- Set the portal user to this company.
3- Add an address and set country to `Argentina`.
4- Assign website to Argentinian company;
5- As the portal user, add something to cart.
6- go to checkout, and save the address.

You will get the error that some fields are missing.

### Cause:

This issue is partially fixed in https://github.com/odoo/odoo/pull/239998. However, there are three issues left:

1. That fix doesn't show the error regarding 'Identification and AFIP Resposibility Types' when we have `use_delivery_as_billing`. As a result a generic error `some fields are missing` is shown.

2. `can_edit_vat` is used in:
https://github.com/odoo/odoo/blob/5b39cdceb84758f767b83b741be927c1a7cfac7a/addons/l10n_ar_website_sale/views/templates.xml#L7-L9
https://github.com/odoo/odoo/blob/5b39cdceb84758f767b83b741be927c1a7cfac7a/addons/l10n_ar_website_sale/views/templates.xml#L32-L35
This needs to also consider `l10n_ar_afip_responsibility_type_id` and `l10n_latam_identification_type_id` being set.

3. Also we need to make sure `Identification Number` which is `vat` is set if we want to prevent it from being modified.

opw-5376149

affected versions: 16, 17

The query for `_sdd_get_usable_mandate` is far from optimal.

An EXPLAIN ANALYZE shows some pain points that we address in this PR: https://explain.dalibo.com/plan/c4eddda16fa4cf39

- Indexing `sdd_mandate` in `account.move` lets the subquery use an Index Scan instead of a full-table Seq Scan.
- Without changing the logic of the subquery it is now way more performant using NOT EXISTS, which avoids the Aggregate node and enables early exit.

These two minor changes yield a ~10x speedup in our tests.

(probably there's more performance to gain, although this seems to be an issue that will cease on later versions)


Some captures on performance over ~2000 payments. Before, a big chunk of the time was spent retrieving the mandate. The more operations the larger the time:

<img width="1246" height="655" alt="image" src="https://github.com/user-attachments/assets/3b6695e1-dbb0-46fa-a22c-fba0e9c2ec2b" />

Now over the same amount of payments, the mandates retrievement isn't that troubling anymore:

<img width="1050" height="609" alt="image" src="https://github.com/user-attachments/assets/63ad88d1-51a0-4607-ae50-8022cf4cffc7" />


cc @moduon MT-11292

fyi @yajo

Forward-Port-Of: odoo/enterprise#97410

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106