## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.

#### Additional
- Mark the field `access_token` as readonly.

task-5051394

Forward-Port-Of: odoo/enterprise#93561

### Issue:

Scanning an unreserved lot of a kit component creates a new barcode line rather than updating the value of the initially reserved lot. As a result, the backorder porcess considers that every unscanned yet initially reserved quantity is to backorder.

### Steps to reproduce:
- Create a kit product with a kit BOM:
    - 1 x COMP (tracked by SN)
- Add two Serial numbers SN001 and SN002 in stock for the COMP product
- Create and confirm a delivery order for 1 unit of oyur kit product
- Go the barcode app to process your delivery
- Scan SN002
> A new line is created instead of updating the initial reservation
- Validate the delivery
#### > A backorder dialog opens proposing to update the unscanned reservation

### Cause of the issue:

Scanning a lot will first try to find a line to update, however, currently a line will only be found if the scanned lot has been reserved or if no particular lot has been reserved:
https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L1659-L1661 https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_model.js#L743-L746 In particular, since no line is considered as valid, a new line is created. And, since this new line does not refer to any `move_id` while the existing one does,  the move with the initial reservation will be backordered considering none of its demand was fulfilled: https://github.com/odoo/enterprise/blob/a1113eebf634302f7ceece612e7ee068c99781e4/stock_barcode/static/src/models/barcode_picking_model.js#L904-L921

### Fix:

In order to loosen the condition of lot override on barcode lines we add a check on the package and the location of the line in order to avoid use cases where the initial move line already contains info's that are proper to the initial lot.

opw-5100026

Forward-Port-Of: odoo/enterprise#99739
Forward-Port-Of: odoo/enterprise#98589

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Forward-Port-Of: odoo/odoo#234908

### Steps to reproduce the issue:

(Easier to reproduce client side with CRM installed)

0. Install crm
1. Create Second Company
2. Create New User with Current Company as Default Company and Second Company in Allowed Companies
3. Create CRM Team belonging to Second Company
4. Add New User to Members of CRM Team
5. Receive error:

>     [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company.

### Explanation:

`crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it.

### Fix reasoning:

Removing restriction, as we want to avoid other multi-company issues by changing the behaviour.

opw-4214192

---

@nd-dew note:
Situation recap
![image](https://github.com/user-attachments/assets/9377ec70-0a57-4a48-b071-de588cde06a6)

So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). 

However looking at the tests it seems like this is desired limitation.

Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority.

Forward-Port-Of: odoo/odoo#189441

When the payment transactions trigger the creation of invoices and then the sending of those invoices by mail and through the EDI to the government, any concurrent update can make that entire process fail all at once.  This mainly happens when the user himself is paying through the portal as this will create the invoice from the payment.

When invoices are sent to the government however, we want to be sure that when sent, it gets updated in Odoo as well, so we are aware what is happening.

The problem we got is that invoice 1 is sent to the government (l10n_in_edi) as number 01 and then that transaction is totally rolled back that the invoice is not even there anymore, it risks that the government's numbers and your numbers do not correspond anymore.

So, we should avoid that that invoice can be sent when before there is a concurrent update (on payment transaction in this case) waiting for destroying it when committing.  So, the simple idea would be to only do the invoice sending through a post commit.  As we are locking the invoice itself for the sending to the government that should be enough to avoid the invoice sending for not being registered in Odoo.

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

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

# How to reproduce the issue:
- Create two currency rates: one for today and one for the day before.
- Create two invoices with different `amount_total`, both using the rate from yesterday.
- Create a group payment dated today.

Check the generated payment, its journal entry, and the reconciled items. Two exchange moves are created — one for each invoice. However, on the invoices themselves, only one of those exchange moves is associated with both invoices.

Since commit 5420e40ff337080912edf7414257e03853be026a, the logic that associates exchange moves to `account.partial.reconcile` records was changed.

It links an exchange move to a partial if any of its reconciled lines match either the partial's `debit_move_id` or `credit_move_id`.

In a group payment scenario:
- Two partials are created (one per invoice).
- Each has a different `debit_move_id` (the invoice lines) but shares the same `credit_move_id` (the single payment line).
- As a result, both partials match the same exchange move via the shared credit line — leading to incorrect assignment.

opw-5147281

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

**Issue**
In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`.

**Steps to reproduce**
1. Go to Inventory > Operations > Procurement > Replenishment
2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order)
3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included

**Cause**
`qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a).

In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results.

Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency.

**Solution**
Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values.

opw-5150643

Forward-Port-Of: odoo/odoo#234908

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#96122

### State of the art:

Control point for the manufacturing operation type are not expected to create QC when they refer to components.

### Steps to reproduce:

- Create a BOM for a final product FP:
    - 1 X COMP (consumable)
- Create a Quality Control Point:
    - Control: Quanity
    - Operations: Manufacturing
    - Product: COMP
- Create and confirm an MO for 1 unit of FP
#### > A QC is created for the component

### Cause of the issue:

Quantity quality checks related to MOs are expected to be created by `_create_quality_checks_for_mo`, which ensures that only moves referring to the production are considered:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move.py#L23-L29
However, each time a `stock.move.line` is created, it triggers the related "quantity" control points if it is not filtered out of the applicable lines:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L28-L35
The issue is that move lines related to `move_raw_ids` are always considered applicable:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L31-L34
and that the `_create_check` triggers "quantity" control points that directly refer to the `product_id` of the move line:
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_control/models/stock_move_line.py#L79-L88

Note, however, that `_create_check` ignores control points of move lines related to a raw move if they do not refer to any product_ids, due to `_get_quality_points_all_products` (which is only called to find control points without a set `product_ids`):
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/quality_mrp/models/stock_move_line.py#L20-L24
This explains why the test `test_04_quality_check_on_quantity` did not trigger the creation of quality checks for components.

### opw-5137594

Forward-Port-Of: odoo/enterprise#97217

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#96122

Currently an error occurs when user change the move line quantity.

Steps to Reproduce [video](https://drive.google.com/file/d/12r0DxsKZkvuVjoCsRgXlHJ23NpaqciV7/view?usp=drive_link):

 - Install the `purchase_stock` module.
 - Create a `product` with category: `Costing Method: FIFO`.
 - Create a `purchase order` and add the newly created product to it.
 - Click `Confirm Order`, then click on `Receipt` and `validate` it.
 - Click on `Moves`, open the record, set the `Quantity to zero`, and `save`.

`ZeroDivisionError: float division by zero`

This error occurs when a user confirms a purchase order, validates its picking, and changes the move line quantity to zero. It then tries to update the move line value and the product's standard price due to the FIFO costing method, but the valued quantity becomes zero from [1], which raises an error at [2].

This commit ensures that if the move line has a zero quantity, the product's standard price remains unchanged.

[1]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/stock_move.py#L333-L343

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/stock_account/models/product.py#L218

sentry-6993648057

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

- Go to Recruitment > Applications > All Applications.
- Open an applicant form and click "Generate Offer".
- Repeat a few times so that the "Offers" smart button shows a list view.
- From the list view, click "New" to create an offer.
- Compare both flows:
  * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window.
  * With "New" button: the generated offer link has `token=False`, which leads to an invalid link.

#### Issue
In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links.

#### Fix
Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user.

#### Additional
- Mark the field `access_token` as readonly.

task-5051394

Forward-Port-Of: odoo/enterprise#93561

## Issue:
When adding landed costs to stock moves, the resulting move value was increased regardless of the quantity remaining in stock
As a result, moves with no remaining quantity could still receive additional value, incorrectly affecting products that are no longer in stock

## Cause:
The valuation is determine using the `move._get_value()` function, which uses the standard price when there is no linked PO, Bill, or Credit Note
However, it distributed the landed cost share based on the move itself, without considering whether the move’s quantity was still available in stock

## Steps to reproduce:
- Create a product (Tracking: Quantity, category: AVCO)
- Receive 2 units of the product.
- Deliver 1 unit
- Create a Landed Cost for the receipt with an additional cost of 100 $
- Open Inventory > Reporting > Move Analysis
- Add Value in Measures
- Look for the current month (add a product filter if needed)
- You should have Quantity: 2 and Value: 50$ after the fix

opw-5128570

Forward-Port-Of: odoo/odoo#232857
Forward-Port-Of: odoo/odoo#231936

## Issue:
When you have an allocation and set a leave for that period, if you add a new allocation for that period and you validate it, it will be impossible to Refuse this allocation later
A UserError was raised asking to remove the leave even if it should be linked to the first allocation created

## Cause:
The `action_refuse()` method for `hr.leave.allocation` uses the `virtual_leaves_taken` value inside the `_get_consumed_leaves()` function's result
That parameter is calculated for the allocation as far as it state is `validate`, for all the leaves in that time interval, including previously created leaves
The leaves will be allocated to the last allocation created, so the last one can't be removed later
As a result, the allocation is considered as already used by these pre-existing leaves, even if the leave can still be modified to return to the state prior to the allocation's validation

## Steps to reproduce:
- Create an initial Allocation (that should end after the next created Allocation)
- Create a Leave from 22/12/2025 to 31/12/2025
- Create an Allocation including the leave period (01/12/2025 to 31/12/2025)
- Validate, then Refuse

opw-4900686

Forward-Port-Of: odoo/odoo#235711
Forward-Port-Of: odoo/odoo#222171

**Steps to reproduce:**
1. Install the `Accounting` and `l10n_ph_reports` modules.
2. Create a contact with the company flag enabled.
3. Create an invoice using that contact.
4. Go to `Reporting → Summary Lists of Sales and Purchases → Sales`.

**Observed behavior:**
* The `Registered Name` column in the report is blank for companies.

**Cause:**
* The query logic was incorrectly showing the registered name only when a last name was present. This issue arose due to the change in how company/individual differentiation is handled.

**Fix:**
* Update the query logic for the Odoo report:
  - **Always display the registered name in the Odoo report**:
    - If individual: show `First Name`, `Middle Name`, `Last Name`.
    - If company: show `commercial_partner_id.name`.
  - **For the export file**:
    - If company: only show the registered name.
    - If individual: show `First Name`, `Middle Name`, `Last Name`.

The fix ensures that **Registered Name** is always displayed in the report, and the export behaves as expected for both individuals and companies.

Note: spec provided by po -> 
<img width="1662" height="431" alt="image" src="https://github.com/user-attachments/assets/a7a58a9e-b769-4815-ad0a-cef9c8e2eff7" />


opw-5143677

Steps to reproduce
-----
- Create a Sendcloud delivery method
- Select a delivery service with "Locker or service point" as "Last mile" (eg  "bpost @ bpack")

> "Use Sendcloud locations" is set to false

Cause
-----
There is a problem with the values retrieved from the Sendcloud API call, more specifically the `available_functionalities` > `last_mile` value.

The Sendcloud API (of both previous and current beta version) specifies the possible values to only be the following
- `home_delivery`
- `mailbox`
- `pobox`
- `service_point`
- null
https://api.sendcloud.dev/docs/sendcloud-public-api/shipping-options/operations/create-a-shipping-option
https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/shipping-products/operations/list-shipping-products

However, it seems like they have added some new undocumented values `locker` and `locker_or_service_point`.

To detect whether to use drop-off locations, we do
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L51-L53

Where we compare the retrieved value with the string 'Service point'
https://github.com/odoo/enterprise/blob/5b64c63301bc814c7c9d99146af6a86d37563762/website_delivery_sendcloud/models/delivery_sendcloud.py#L13

In our "Locker or service point" case, this does not work because the `in` operator makes a case sensitive comparison.

Solution
-----
Functionally, both lockers and service points work the same. The user should be prompted a map on which they choose where the delivery should be dropped off.

So we can add `Locker` and `Locker or service point` as accepted values and enable the use of sendcloud locations for both.

-----
Ticket:
opw-5217796

Forward-Port-Of: odoo/enterprise#98875

Steps to reproduce:
-------------------------
1. Install Website and AI modules.
2. Open the website editor.
3. From the Intro block, search for the AI snippet and add the snippet contains 'Need Help?'.
4. Click on the added block, then click the Save icon from the Style tab.
5. Save the snippet
6. Go to Blocks → Custom Blocks and add the saved snippet.

Observation:
-------------------------
A traceback is raised:
```
TypeError: Cannot read properties of null (reading 'remove')
    at AILivechatOptionPlugin.onSnippetDropped
```

Issue:
-------------------------
The `onSnippetDropped` method
https://github.com/odoo/enterprise/blob/bb3699cc112acb3ec545d3aa5f3d8f7263a5dac6/ai_website_livechat/static/src/website/plugins/ai_livechat_option_plugin.js#L39-L51 executes every time a snippet is dropped into the layout. When the snippet is first added, the method removes the `<div>` with class `s_ai_livechat_preview`. Upon saving, the snippet is stored without that `div`. When re-adding the saved snippet from custom tab, the method runs again but fails since the `s_ai_livechat_preview` element no longer exists, resulting in the traceback.

Solution:
-------------------------
Added the optional chaining operator to safely remove the `s_ai_livechat_preview` div only when it exists.

opw-5227072

### Steps to reproduce:

- Go to Inventory > Reporting > Stock
- Toggle studio and enable debug mode
- Click on the "On Hand" column
#### > UncaughtPromiseError > OwlError > Uncaught Promise:
> Got duplicate key in t-foreach: /list[1]/field[x]_hide_trailing_zeros

#### Note:

We enabled debug mode to raise template rendering issues but without debug mode the template of the left studio panel is simply not rendered.

### Cause of the issue:

The `qty_available` displayed in the `product.product` list view https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/views/product_views.xml#L574-L575 is associated with a `stock_action_field` widget. However, since e4c51ad8a6da17339923875de7fa303544b717e1 this widget has become an hybrid entity able to support both the float and the monetary fields: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/static/src/fields/stock_action_field.js#L12-L22 The issue is due to the fact that the template of sudio component `TypeWidgetProperties` can not be rendered for our `qty_avaialble` field as it receives the `hide_trailing_zeros` boolean attribute twice in this `t-foreach`:
https://github.com/odoo/enterprise/blob/4ba22ee091938d382fb79ef386b4761e4e15479a/web_studio/static/src/client_action/view_editor/interactive_editor/properties/type_widget_properties/type_widget_properties.xml#L23-L25 
This happens because the `stock_action_field` adds it twice in its supportedOptions:
https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/stock/static/src/fields/stock_action_field.js#L55-L67 once because of the `floatField.supportedOptions`: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/web/static/src/views/fields/float/float_field.js#L119-L124 and once because of the `monetaryField.supportedOptions`: https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/web/static/src/views/fields/monetary/monetary_field.js#L113-L118

opw-5188594

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

**Steps to reproduce:**
1. Install eCommerce.
2. Open a product > Sales Tab > Alternative Products
3. Add products with  an internal reference (default_code) and Attributes.
4. Go to website > scroll down to the alternative products section.

**Issue:**
- The "Alternative Products" snippet displays the product's internal reference 
  in the title.
- This occurs only for products with attributes and variants(attribute_line_ids)
- The behavior is inconsistent with the main product page, where only the 
  product name is shown

Cause :
- The QWeb template was accessing the product name through values['data']['_record'] (which is a product.template) 
whose display_name includes internal reference  (e.g., [E-COM06] Corner Desk Right Sit).
 This occurs for products that have attribute_line_ids.
https://github.com/odoo/odoo/blob/f0a34badefd432e9c2ab36acaf018d20d0e342fe/addons/website_sale/data/product_snippet_template_data.xml#L17-L20
    <img width="1920" height="458" alt="image" src="https://github.com/user-attachments/assets/c3088149-b6c8-4cd7-8db4-129f0282a09d" />
- However, values['data'] already contains a clean display_name 
  (e.g., Corner Desk Right Sit) i.e. as expected.

**Solution:**
- Updated the QWeb template to use the correct field from the prepared data:
             `t-out="data.get('display_name') or product.display_name"`
- This ensures that the title displays a clean product name consistent with the
   main product page, without the internal reference

**opw-5122632**

Steps to reproduce:
---------------------------
1. Install the Recruitment app with demo data.
2. In Settings, add an Email Alias for the company.
3. Open the Recruitment app.
4. Click the Configure button on the job position kanban card.
5. In the Job Position form view, add an email alias.
6. Use the breadcrumbs to navigate back to the job positions.

Observation:
---------------------------
The email field for the job position is misaligned in the kanban card.

Issue:
---------------------------
The `div` containing the email is missing a `justify-content-*` class https://github.com/odoo/odoo/blob/5ab45d45073463495e517aca9fd061415a73e893/addons/hr_recruitment/views/hr_job_views.xml#L77

Solution:
---------------------------
Add the missing `justify-content-between` class to align the email properly.


Before:
<img width="1909" height="749" alt="before" src="https://github.com/user-attachments/assets/51790c71-f30d-4402-ae24-a5ccfb30ff9a" />

After:
<img width="1914" height="697" alt="after" src="https://github.com/user-attachments/assets/711f83f6-208e-44c3-83e2-8b736c697a9d" />

opw-5246587

### Issue

Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).

### Analysis

Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.

### Solution

Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.

For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.

### Benchmarks

Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types

| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |

### References

opw-5130725

In the POS of a Mexican company, when requesting an invoice, the user
is asked to set the invoice to public or not. If the customer does not
have a recognized ZIP code or country, setting the invoice to public
**should not** raise an error, but it does. This is because the
`l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM,
which leads to the UserError below being triggered, as
`l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not
updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a *compute field*.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: \[[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)\]

To minimize behavioral changes, the required field
(`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not
longer raised when the *Invoice to Public* field is set to "Yes"
in the POS.

### Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"*
and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#98983

Versions
--------
- 18.0+

Steps
-----
1. Have a minimal database with `event_product` installed;
2. run `:TestEventProduct.test_ensure_event_service_tracking`.

Issue
-----
> FAIL: TestEventProduct.test_ensure_event_service_tracking
> AssertionError: ValidationError not raised

Cause
-----
The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30

This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183

As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised.

Solution
--------
Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected.

runbot-234024

Steps to reproduce [A]:

- Go to website ("edit" mode) > Add a new "Media List" snippet.
- Select one of the snippet items > An empty "Column" options section
will appear on the sidebar and an overlay will be covering the item.

After [1], grid layout options were updated to be able to set grid items
padding individually, the new snippet option used for that
(see: `GridColumns`) is targeting every `.row > div` and uses the widget
visibility code to be sure that the option is available only in "Grid"
mode, which leads to the behaviour described above.

There is already an implementation to prevent sections with hidden
widgets from being visible (see: `updateOptionsUIVisibility()`) and
adapt the overlay accordingly, but it only handles specific situations:

[B]- The implementation on [2] (used to move the switchable views to a
`SnippetOption`) led to a situation where an empty "Page Options" editor
was visible on every page.

[C]- This visible section issue from [B] was fixed (see [3]) by hiding
the `snippetEditor` if none of its options are visible (including the
`we-top-button-group` options).

[D]- Even with a hidden "Page Options" `SnippetEditor`, its overlay will
always be visible (with an empty options tab) when the `<main/>` element
is clicked. The code from [4] fixed a specific situation of the issue:
The code will hide the overlay only if there are no options at all
(`customize$Elements === null`), which is the case for `SwitchableViews`
(e.g. for a `SnippetEditor` with parent editors, we only need to hide
the overlay if its `$optionsSection` is empty).

The goal of this commit is to fix the behaviour described in [A] in two
simple steps:

- Allow hiding the `snippetEditor` even if it contains visible
`we-top-button-group` options, since an editor with no
`we-customizeblock-option` is enough to prevent its visibility (also,
the fix in [3] was specifically introduced to hide the "Page Options"
editors).

- Generalize the check from [4] to hide the overlay of every editor with
an empty options section.

[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
[2]: https://github.com/odoo/odoo/commit/69af7dcfeb3ff95c40b00ef0cc7c5c0e4021f9d2
[3]: https://github.com/odoo/odoo/commit/39d073ccafddf4b3fbe9ec9f5f11849d77c9bdaa
[4]: https://github.com/odoo/odoo/commit/fccac358dae7092c8c7cd90ba1ee89c712bc86e9

task-3658153