## Steps to reproduce

- Create an attribute A, of type always, with 2 values, one should have an extra price
- Create an attribute B, of type never, with 2 values
- Create a product that has both those attributes
- Create a combo with that product with both values for A
- Go to the PoS and order that combo with the value that has an extra price for A
- The extra price is added

## Why the fix:

For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo.

As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page.

It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always".

The variants are then considered as different products, as they should in this case.

If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it.

We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 

We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same.

opw-6262431

Forward-Port-Of: odoo/odoo#270894
Forward-Port-Of: odoo/odoo#268567

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

**Steps to reproduce:**

- Enable "Track orders edits" in the settings
- Enable "Log in with Employees"
- Go to the Restaurant, log in with employee A
- Go to a table, order 3 Sushis
- Go back to the floor plan and change to employee B
- Go back to the table and change the qty of 3 Sushis to 2 Sushis
- Go to the order in the backend and check the chatter
- It will indicate that employee A did the change, but it was employee B

**Why the fix:**

We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point.

We now use the session's current employee to write who did the change in the chatter.

We do not change the order's employee, because it will be done once the order has been paid.

In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and
browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name.

The way we return the value has been changed because the linter wasn't happy about it.

opw-6213504

Forward-Port-Of: odoo/odoo#270768
Forward-Port-Of: odoo/odoo#265582

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/da121002d2 [REL] 19.3.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9c9ea4006a [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764)
https://github.com/odoo/o-spreadsheet/commit/8c5b03b36e [FIX] composer_tokenizer: fix argument separator in formulas [Task: 6303210](https://www.odoo.com/odoo/2328/tasks/6303210)
https://github.com/odoo/o-spreadsheet/commit/4a9480b602 [IMP] node: add script to run the model in node [Task: 6088515](https://www.odoo.com/odoo/2328/tasks/6088515)
https://github.com/odoo/o-spreadsheet/commit/b9dd4f4ae4 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5856475544 [FIX] carousel: custom color don't use carousels [Task: 6263128](https://www.odoo.com/odoo/2328/tasks/6263128)
https://github.com/odoo/o-spreadsheet/commit/396acb35d2 [FIX] charts: pie chart shows empty chart for text entries [Task: 6275525](https://www.odoo.com/odoo/2328/tasks/6275525)
https://github.com/odoo/o-spreadsheet/commit/ed39af1898 [FIX] charts: pass `onDataSetHover` to chart config [Task: 6233312](https://www.odoo.com/odoo/2328/tasks/6233312)
https://github.com/odoo/o-spreadsheet/commit/3baf99b853 [FIX] table: correctly insert table on static pivots [Task: 6204984](https://www.odoo.com/odoo/2328/tasks/6204984)

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>

*: hr_holidays,test_discuss_full

**Steps to reproduce,**
Create an employee linked to a user
Archive the employee and remove the link to the user
Create another employee for the same user
Go to Discuss > 'General' channel
Open the member list and click on the user's avatar

**Before this commit,**
Clicking on the avatar opened a popover showing outdated information from the
archived employee record instead of the new one.

**Cause,**
By default, the server sends employee data ordered by name. Since both records
have the same name, the order is non-deterministic. The client then attempts to
match the employee's company to the current user's company, falling back to the
first record in the list if no match is found.

**Fix,**
Filter out archived records first (treating them as non-existent). Then, sort
the remaining employee records to prioritize those that match the current user's
active company. In case records share the same company, prioritize employees
with a related user. Fall back to descending order of creation for identical
results.

**After this commit,**
Clicking on the avatar shows the correct employee details in the popover.

task-6175765

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

Forward-Port-Of: odoo/odoo#270546
Forward-Port-Of: odoo/odoo#252170

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe

Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
    - opA: no blocker
    - opB: blocked by opA
    - opC: blocked by opA
    - opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan

Problem:
opA was scheduled after opB, violating the dependency.

`_plan_workorders` starts planning from the "leaf" workorders (those
with no dependents). Given the structure above, the initial set is
[opB, opD]. Processing opB first correctly plans opA then opB. But
processing opD triggers a recursive chain opD→opC→opA which calls
`action_unplan(opA)` and replans it from scratch. By then, opB already
occupies the workcenter slot that opA originally held, so opA ends up
scheduled after opB.

Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.

opw-6299179

Steps to reproduce:
- Install Attendance + Timesheets
- Disable "Attendances from Backend"
- Timesheet icon disappears from toolbar
 
Current behavior:
Bridge module permanently removes the `timesheet systray` from
the `registry` and merges it inside the attendance dropdown.
When `attendance_from_systray` is off, the dropdown hides itself
and takes the timesheet icon with it, leaving no way to log
hours from the toolbar.
 
Expected behavior:
Timesheet icon should remain accessible when attendance from
systray is disabled.
 
Issue:
`registry.remove()` at module load made the timesheet icon
impossible to restore.
 
Fix:
Keep the timesheet systray registered. Patch TimesheetSystray
to read `display_systray from lazy_session` on startup and show
itself standalone when attendance from systray is off.
 
The template no longer replaces nodes. Header and total_hours
are toggled via `position="attributes"` (`t-if="!props.signInOut"`,
a prop only passed by the attendance dropdown), and a
self-contained dropdown-only footer with the Check out button
is added after total_hours.

Ref: odoo/enterprise#104347
task-6285068

Steps to reproduce the bug:
- Go to contact:
    - azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
    - a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it

Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.

In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.

Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.

opw-6167835

Forward-Port-Of: odoo/odoo#270735

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/dce4ae7d4f [REL] 19.1.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b09fce3cc8 [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764)
https://github.com/odoo/o-spreadsheet/commit/28177797ff [FIX] composer_tokenizer: fix argument separator in formulas [Task: 6303210](https://www.odoo.com/odoo/2328/tasks/6303210)
https://github.com/odoo/o-spreadsheet/commit/f70fba15e9 [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/8377e1112a [IMP] node: add script to run the model in node [Task: 6088515](https://www.odoo.com/odoo/2328/tasks/6088515)
https://github.com/odoo/o-spreadsheet/commit/458bba3f53 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/60cc12db7c [FIX] carousel: custom color don't use carousels [Task: 6263128](https://www.odoo.com/odoo/2328/tasks/6263128)

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 work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/odoo#268527

Issue:
When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.

Steps to reproduce:
- Create an employee with Work Entry Source set to Attendances
- Use a flexible working schedule on the employee
- Configure a public holiday on a scheduled day with work entry type (Paid time off)
- Create a time off type with Count as set to Worked Time
- Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after)
- Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry)

Cause:
In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into:
- leaves: absences and public holidays
- worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226

For non-flexible calendar:
Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260

For flexible calendar:
The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249

Solution:
We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created:
- for fully flexible employees, subtract regular leaves from worked leaves;
- for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves
- for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule.
  
This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period.

opw-6237163

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

Forward-Port-Of: odoo/enterprise#119530

When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db.

**Steps to reproduce**

* In settings activate:
  - Lots & Serial Numbers
  - Units of Measure & Packagings
  - Storage Locations
  - Barcode Scanner : GS1 nomenclature
* Create a Product tracked by lot with
  - barcode: 00001234567895
* Add on hand quantity:
  - 100 kg in lot : 10002002303-4
  - 100 kg in lot : 11002002303-4
* Go to barcode>Operation>Internal Transfer>New
* Scan 02000012345678951010002002303-4#3100000100 meaning:
  - 02 following 14 characters are the product barcode
  - 10 following characters are the lot number
  - "#" separator
  - 3100: means the units are kilograms, 
  - 00100 means 100 units. 

-> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot)

**Observation**

When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717

- First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14
- Check if the data is in the cache, if not, set it to retrieve after
- Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search:
https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 
-> Since our barcode start with a 10, it will erase it, which lead to a miss in the search.


It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298

opw-6207120

Forward-Port-Of: odoo/enterprise#118828

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/385ca22ca0 [REL] 18.3.52 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1ae7309a35 [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764)
https://github.com/odoo/o-spreadsheet/commit/ae6ba64e54 [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/d2c9c7ff1e [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

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>

Description of the issue/feature this PR addresses:

`Registry.check_indexes` derives a column index's name as `<table>__<column>_index`, which does **not** encode the access method, and only creates the index when no index of that name already exists. It never inspects the access method of an existing index.

As a consequence, changing a field's `index=` kind on an **already-indexed** column is silently ignored on existing databases. For example `account.move.name` was changed from a plain btree index to `index='trigram'`:

```python
name = fields.Char(
    ...
    index='trigram',
)
```
On a fresh database this creates the expected GIN/trigram index. On any database that already had the btree index, the old btree index keeps its name, so `check_indexes` finds the name present and does nothing. The `(=)ilike` searches the trigram index was meant to accelerate keep falling back to sequential scans, with no error or warning.

Current behavior before PR:

### Steps to reproduce

1. Install a module on an existing DB while a `Char` field is `index=True` (btree).
2. Change the field to `index='trigram'` and upgrade the module.
3. `\d <table>` in psql — the index is still `USING btree`, not `USING gin`.

Desired behavior after PR is merged:

`check_indexes` now also reads each existing index's access method (`pg_am.amname`). When the method no longer matches what the field expects (`gin` for trigram, `btree` otherwise), the stale index is dropped and recreated. The drop is issued inside the **same savepoint** as the recreate, so a failed rebuild (e.g. a lock timeout) rolls the drop back and never leaves the column without an index.

Scope: only the access method is reconciled. A change that alters solely the partial predicate (`btree` -> `btree_not_null`) keeps the same method and is intentionally left untouched.

### Notes

- This extends the existing index-management logic in place and keeps the current "keep unexpected index" behaviour for fields that dropped `index=` entirely; only fields that still want an index, of a different method, are rebuilt.
- Trigram rebuilds still require the `pg_trgm` extension; without it the GIN index is skipped exactly as before (`self.has_trigram` guard).


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

Forward-Port-Of: odoo/odoo#271077
Forward-Port-Of: odoo/odoo#268505

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Community: https://github.com/odoo/odoo/pull/271017

opw-6275658

Forward-Port-Of: odoo/enterprise#121135

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160

Forward-Port-Of: odoo/enterprise#120873
Forward-Port-Of: odoo/enterprise#115446

When creating a payslip for an employee in the Belgian localization with
an hourly wage and an attendance-based work entry source contract, a
traceback occurs if there is an attendance with overtime.

This happens because the overridden `_preprocess_work_hours_data_split_half`
method in `l10n_be_hr_payroll_attendance` attempts to unpack `work_entries`
assuming it is a list of triplets, but it is passed as a `defaultdict`
with composite keys instead. This data structure mismatch results in a
`ValueError: not enough values to unpack (expected 3, got 2)`.

Even if updated to handle the `defaultdict` structure, `_preprocess_work_hours_data_split_half` would improperly delete the overtime line hours without adding them back elsewhere (the code responsible for adding them back seems to have been removed). Since this function serves no purpose anymore, we omit the call to it. However, because `saas-19.2` is a stable version
Task Id: 6253707

Forward-Port-Of: odoo/enterprise#119177
Forward-Port-Of: odoo/enterprise#118676

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120866
Forward-Port-Of: odoo/enterprise#120051

Version
- saas-19.3

Steps to Reproduce:
1. Create a custom Sign field (e.g. "Passport No") with "Update Field" enabled, linked to Employee (For Applicant, same any custom field).
2. Employee flow: Employee app -> open an employee -> gear icon -> Signature Request -> send.
   Applicant flow: Recruitment app -> Applicants list view -> select an applicant -> Actions -> Signature Request -> send.
3. Complete the signature.
4. Check the linked record's "Passport No" field -> field is not updated.

Issue:
The field linked to the employee/applicant record is not updated after signing.

Cause:
Both the `hr.contract.sign.document.wizard` and `hr.recruitment.sign.document.wizard` create the `sign.request` in `validate_signature()` without setting `reference_doc`. `_get_auto_field_target_record()` relies on `reference_doc` to resolve the record to sync auto fields against. With `reference_doc` empty, it returns `None`, so `sign.request._sync_auto_field_value()` skips the item before it ever reaches the write step.

Solution:
Set `reference_doc` to the corresponding `hr.employee`/`hr.applicant` record when building the `sign.request` values in `validate_signature()`, so auto fields linked to those models can resolve their target record and sync back normally after signing.

taskid-6308532

Forward-Port-Of: odoo/enterprise#121152

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

Forward-Port-Of: odoo/enterprise#119161

When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference.

### Current Implementation
The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`.

### Proposed Fix
This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity.

The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest
labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced.

Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process

### speedup

In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption.

Because of the memory consumption it was not possible to gather timing value on the current version. 
Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database
(831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms.

**Problem:**
partial quantities in a dropship picking 
is not taken into account for the svl quantity
(it's always the full initial quantity)

**Steps to reproduce:**
- create a storable product with dropship route
- set the category as avco auto
- set a vendor in the purchase tab with a price of 10
- confirm a SO for a quantity of 2
- confirm the related PO with a unit price of 10
- on the dropship picking change the quantity to 1
- validate without backorder
- click on the valuation smart button

**Current behavior:**
- the svls have quantities of 2 and -2
- the related amls have debit/credit of 20

**Expected behavior:**
- the svls should have quantities of 1 and -1
- the related amls should have debit/credit of 10

**Cause of the issue:**
when creating the svls we use the move's product_qty
instead of its quantity
https://github.com/odoo/odoo/blob/c97629d5efb82aed191de211593c539686cae65b/addons/stock_account/models/stock_move.py#L290

**fix:**
product_qty is expressed in the uom of the product
and quantity in the uom of the move so we need 
to add a uom conversion to the fix

opw-6113031

Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views

Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").

Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.

Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.

Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999

opw-6238765

Steps to reproduce:
===================
1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates
2. Open /customers
3. Open the map and zoom in a few times

=> stale blue cluster bubbles remain on the map

Cause:
======
On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level.

`ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map,
https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation.

Solution:
=========
Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon.

opw-6128531

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

Avoid traceback when there is special hidden characters on the VAT numer, compact() method from stdnum does not process it.

We use regex to get only the number part for all the doc types

### Description of the issue/feature this PR addresses:

1. Create new contact
2. add cuit value (in the vat field). This one is copy from an external program with special hidden characteres

### Current behavior before PR:

There is a traceback and the user can not create the contact

```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/addons/l10n_ar/models/res_partner.py", line 123, in _get_id_number_sanitize
res = int(stdnum.ar.cuit.compact(self.vat))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '\u206030717808599'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30061:19)
at XMLHttpRequest.<anonymous> (https://brunetti.adhoc.ar/web/assets/1/debug/web.assets_web.js:30124:27)
```
### Desired behavior after PR is merged:

Will let us to create the contact and validate the cuit no matter if it has or not an special character



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

**Steps to reproduce:**
* Install the **l10n_in_reports** module.
* Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**.
* Activate a foreign currency (e.g., USD) and set an exchange rate.
* Create a new vendor bill for an Indian vendor, setting the currency to USD.
* Add lines to the bill and apply IGST/GST taxes, then confirm the bill.
* Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR).

**Observed behavior:**
* The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match.

**Cause:**
* The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR).
* The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields.
* Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched.

**Fix:**
* Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`.
* This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR).

opw-6311097

Forward-Port-Of: odoo/enterprise#120967

### Issue
`l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises:

```
TypeError: Model 'certificate.certificate' does not exist in registry.
```

### Cause
`models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`.

### Notes
- Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op.
- Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first.

The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one.

### **Steps to reproduce:**
1) Install time off app.
2) Create a simple time off type.
- Create Allocation A (10 days, 01-01-2024 to 31-12-2025)
- Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 
3) Create a leave of 1 day on 01-01-2026
4) Open the Balance report

### **Observed Behavior:**
The report shows 20 remaining days.

### **Expected Behavior:**
The report should show 19 remaining days (20 allocated - 1 taken).

### **Cause:**
In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula:
```
GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0)
```
This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them.

[1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142

[fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164

### **Fix:**
Ensure that leaves are only deducted from allocations they actually
overlap by calculating the balance using the delta of cumulative leaves
within an overlap group. This prevents earlier allocations from absorbing
leaves that occur outside their validity period.

**opw-6150161**

Description of the issue/feature this PR addresses:

When an invoice has advance payment lines that exactly cancel the product lines (net taxable base = 0 per VAT aliquot), floating-point accumulation
in `_aggregate_base_lines_aggregated_values` leaves a tiny residual
(e.g. ~1e-12). This residual is truthy in Python, so `_get_vat()` adds
the aliquot entry to the result even though both `BaseImp` and `Importe`
round to `0.00`. The AFIP WSFE web service receives a non-null `Iva`
block with all-zero amounts instead of `null`.

## Steps to reproduce

1. Create an invoice with one or more product lines (IVA 21%, for example).
2. Apply an advance payment that fully cancels those lines.
3. Confirm the invoice and inspect the generated WSFE XML preview.
4. **Before fix:** `Iva` contains `{'AlicIva': [{'Id': '4', 'BaseImp': '0.00', 'Importe': '0.00'}]}`.
5. **After fix:** `Iva` is `null`.

## Root cause

`_get_vat()` checked the raw (unrounded) aggregated float values in the
filter condition:

```python
if ... and (values['base_amount_currency'] or values['tax_amount_currency']):




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 the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up.

## Benchmarks
|Record count|Time before|Queries before|Time after|Queries after| 
|------------|-----------|--------------|----------|-------------|
|6,262       |0.13s      |68            |0.12s     |68           |
|68,882      |0.60s      |112           |0.58s     |109          |
|432,317     |5.49s      |398           |3.68s     |309          |
|757,702     |15.33s     |1,141         |5.79s     |599          |

[opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)

The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24)
override builds link.tracker short URLs from
`website.get_current_website()` and the current company's website
domain. It was introduced by
https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a
for a multi-company backend flow (users switching companies to post
social marketing links), but it runs for every compute, including
CRON contexts with no HTTP request such as the mass-mailing queue.

Without a request, `get_current_website()` picks an arbitrary website
(the first in the database) and `self.env.company` resolves to the
user's main company, so the short URL uses that company's website
domain instead of `web.base.url`.

Fall back to `super()._compute_short_url_host()` (which uses
`web.base.url`) when no website is resolvable from the request,
session, or context. Backend flows with a real request still hit the
company-aware branch.

Steps to reproduce:
1. Install Email Marketing and Website.
2. Settings > Companies: create a second company B. Settings >
   Websites: ensure website A points to company A with domain A, and
   create website B for company B with domain B.
3. Settings > Technical > Parameters > System Parameters: set
   `web.base.url` to a third domain C, and add `web.base.url.freeze`
   = `True`.
4. On company A, Email Marketing: create a mailing with body
   `<a href="http://example.com">test</a>` and a recipient list,
   then click Send.
5. Settings > Technical > Automation > Scheduled Actions > "Mass
   Mailing: Process queue" > Run Manually.
6. Email Marketing > Configuration > Link Tracker: open the tracker
   generated for the mailing.

=> The Tracked URL uses domain A.
=> The Tracked URL uses domain C.

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