## Previous Behavior Before this Commit
1. When key and non‑key events were merged to build the final suggestion timeline, key events always took priority over AFK events, even when the key event was not “always active.” This caused AFK events to be incorrectly overridden.
2. During event normalization, certain events were lost entirely, resulting in important events not being counted.
3. When merging two event timelines, zero‑duration gaps were treated as valid, preventing proper merging of surrounding events.
4. ActivityWatch sometimes produced empty gaps instead of AFK events, causing breaks to go unrecorded.

## New Expected Behavior After this Commit
1. Events now follow the updated priority system: 
a. Always‑active key events 
b. Always‑active non‑key events 
c. Non‑key AFK events 
d. Other key events 
e. Other non‑key events
2. Events are now shortened or split so that the latest event always has priority, while minimizing unnecessary event removal.
3. Zero‑duration gaps are skipped when merging event lists.
4. Any gap larger than 3 minutes, between the first and last event and containing no events is automatically filled with an AFK event.

## Additional Notes
Because point 4 introduces additional AFK events, several tests were updated to reflect the new behavior.

task-[6455412](https://www.odoo.com/odoo/project/4105/tasks/6455412)

Forward-Port-Of: odoo/enterprise#128039
Forward-Port-Of: odoo/enterprise#127811

### Problem

`stock.move.line.scheduled_date` is related to `move_id.date`, and `stock.move.date` only holds the scheduled date **until the move is done** — at validation it is overwritten with the processing date, as its own help states. So on a done move line the field returns the effective date under a "Scheduled Date" label.

It shows up in Moves History (Inventory > Reporting), which lists done lines by default: filtering, grouping or sorting by "Scheduled Date" silently uses the effective date, and it contradicts the "Scheduled Date" displayed on the transfer, which does survive the validation (`stock.picking._compute_scheduled_date` ignores done moves).

**Steps to reproduce**

1. Create a receipt scheduled tomorrow and validate it today.
2. Inventory > Reporting > Moves History, group by "Scheduled Date".
3. The line falls under today instead of tomorrow, while the transfer form still shows tomorrow.

### Fix

Follow `picking_id.scheduled_date`, which keeps the scheduled date once the transfer is done. The field is only displayed in `stock.view_move_line_tree_detailed`, and every action using that view (`stock.action_get_picking_type_operations`, the Prepare Wave actions and the Add to Wave wizard) already restricts the lines to those belonging to a transfer, so no view loses a value it used to show.

I hereby agree to the terms of the CLA available at: https://www.odoo.com/cla

Currently when the user does manual replenishment no notification is displayed.

## Steps to produce:
- Install Inventory and Purchase
- Create a product `Chocolate Icecream` and Enable `Track Inventory`
- Purchase > Add a Vendor `Ice cream man`
- Reordering rules > Create a new reordering rule and save:
  - Trigger: Manual
  - Min: 5
  - Max:10
- Press the `Order` button

## Observed Behavior:
No notification is displayed about the newly created purchase order.

## Root cause:
When the Order button is pressed, the `action_replenish` method is called. This method invokes `_procure_orderpoint_confirm` at [1].

The `_procure_orderpoint_confirm` function is responsible for creating procurements from orderpoints. During this process, it retrieves the procurement values using `_prepare_procurement_values` that are later used at [2].

However, `_prepare_procurement_values` only includes the orderpoint in the procurement values when the orderpoint's trigger is set to automatic, and not when it is manual, as shown at [3].

These procurement values are then used by `_run_buy` to create a purchase order and purchase order line at [4].

Since the orderpoint is not linked to the purchase order line in this case, no matching order is found at [5], which leads to the reported issue.

**Which commit caused this unintentional behavior?**
This behavior was unintentionally introduced by this [commit](https://github.com/odoo/odoo/commit/2a0d2c64d0027f540101447289b4c1a10cb3ecdf) . That commit fixed an issue where purchase order lines were not being merged for temporary manual orderpoints that are created dynamically based on product demand.

[1]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L342-L349 
[2]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L737-L741 
[3]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L687-L701 
[4]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/purchase_stock/models/stock_rule.py#L156-L165 
[5]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/purchase_stock/models/stock.py#L276-L296 

[6]-
https://github.com/odoo/odoo/blob/c076281dedeed2e25844c43c49ec17511434e3fc/addons/stock/models/stock_orderpoint.py#L365 
[7]-
https://github.com/odoo/odoo/blob/6a84d3e519892be333552e2e0ebf8da87e0a760c/addons/purchase_stock/models/purchase_order_line.py#L380-L384

## Solution:
Instead of removing the orderpoint ID from the procurement values, we reuse the same conditions used to identify temporary orderpoints for cleanup at [6]. Based on this, we determine how purchase order lines should be merged in the `_run_buy` method.

With the previous implementation, no orderpoint was included in the procurement values. As a result, the condition at [7] checking for orderpoints always evaluated to True, causing the system to identify an existing purchase order line for the same product as a merge candidate.

This solution allows us to retain that fix as well as avoid the error of notifications not showing up.


opw-6311520

Forward-Port-Of: odoo/odoo#283853
Forward-Port-Of: odoo/odoo#271993

**Problem:**
Clicking the "Recorded" smart button on a field service intervention raises an AttributeError instead of listing the timesheets logged on it.

**Steps to reproduce:**
1. Install the field service billing feature (Planning > Configuration > Settings > Field Service > "Invoice your time and materials to your customers") without installing Project's planning integration
2. Set the project in Planning > Configuration > Settings > Field Service
3. Create an intervention and assign a resource to it
4. Click the "Recorded" smart button

**Current behavior:**
'super' object has no attribute 'action_open_timesheets'

**Expected behavior:**
The timesheets logged on the intervention are listed.

**Cause of the issue:**
`action_open_timesheets` on `planning.slot` is defined in two modules only: `project_timesheet_forecast` provides the base implementation, and `planning_field_service_sale_timesheet` extends it through `super()`. Since `59a04091c403` dropped `project_timesheet_forecast_sale` from the dependencies of `planning_field_service_sale_timesheet`, nothing guarantees the base implementation is part of the model's inheritance chain anymore: `project_timesheet_forecast` is auto installed only together with `project_forecast`, which no module of the field service stack depends on. The smart button is rendered by `planning_field_service_sale_timesheet` itself, so it stays visible in such an installation while the `super()` call has nothing to resolve to.

**Fix:**
That same commit already made the field service module self-sufficient for `_get_timesheetable_project`, `_compute_allow_timesheets` and `_compute_allow_billable`, leaving the project forecast flavour to the `project_timesheet_forecast_field_service_sale` bridge, and `action_open_timesheets` is the only method that was left relying on the other stack. Building the action from the module's own hooks preserves that separation, whereas depending on `project_timesheet_forecast` again would pull Project back into every field service installation, which is precisely what that commit set out to avoid.

opw-6391972

Forward-Port-Of: odoo/enterprise#126489

Steps to reproduce:
-------------------
1. Install `stock` module.
1. Enable the "Storage Locations" from setting.
2. Create an internal location and enable `replenish_location` on it and set warehouse(WH) as Parent.
3. Create a storable product track by quantity with no on-hand quantity.
4. Create an internal transfer from the warehouse stock location to the new internal location.
5. Confirm the transfer.
6. Open the Replenishment report.

Issue:
------
No manual reordering rule is created for the product at the source location, although 
the confirmed transfer makes its forecasted quantity negative.

If `replenish_location` is disabled on the destination, the expected reordering rule is created.

Cause:
------

When both the source and destination have `replenish_location=True`, Odoo considers both locations 
inside the same replenishment area. Therefore, the internal transfer is not counted as either
incoming or outgoing, and no replenishment is created for the source location.

Code Flow: 

Opening the Replenishment report calls
`stock.warehouse.orderpoint.action_open_orderpoints()`, which delegates the report preparation to `_get_orderpoint_action()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L324-L326

`_get_orderpoint_action()` first obtains every location that must be monitored for replenishment through `_get_orderpoint_locations()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L520

`_get_orderpoint_locations()` returns all locations whose `replenish_location` field is enabled:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L799-L800

All these locations are passed together to
`product.product._get_domain_locations_new()`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/product.py#L396-L464

This method treats the provided locations and their descendants as a set. Its move domains are equivalent to:

- incoming: destination is inside the set and source is outside;
- outgoing: source is inside the set and destination is outside.

Consider the following sibling locations:

    WH
    ├── Stock
    └── Replenish Location

and the transfer:

    Stock -- 3 units --> Replenish Location

When `replenish_location` is disabled on the destination, the considered location set contains only `Stock`:

    considered location set = {Stock}

The source is inside the set and the destination is outside:

    source inside       = True
    destination outside = True

The transfer therefore matches the outgoing domain:

    source inside AND destination outside
    True          AND True
    = True

It is included in `moves_out`, and the preliminary forecast for `Stock` becomes:

    0 on hand + 0 incoming - 3 outgoing = -3

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L552

The negative quantity is detected and a manual orderpoint is created.

When `replenish_location` is enabled on the destination, both sibling locations belong to the considered location set:

    considered location set = {Stock, Replenish Location}

Both ends of the transfer are now inside:

    source inside       = True
    destination inside  = True
    destination outside = False
    source outside      = False

The transfer matches neither aggregate domain:

    incoming:
    destination inside AND source outside
    True               AND False
    = False

    outgoing:
    source inside AND destination outside
    True          AND False
    = False

The transfer is considered internal to the considered location set and is therefore absent from both `moves_in` and `moves_out`:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L530-L540

This aggregate treatment conflicts with the next step, where `_get_orderpoint_action()` computes the quantity separately for each replenishment location:

https://github.com/odoo/odoo/blob/12a66c6931d81e1cce18f676836aca0b32090d16/addons/stock/models/stock_orderpoint.py#L549-L552

When `Stock` is evaluated separately, the internal transfer has already been discarded. Its calculated outgoing quantity is consequently zero:

    0 on hand + 0 incoming - 0 outgoing = 0

As the quantity is not negative, the product is not scheduled for the final `virtual_available` computation and no manual orderpoint is created.

Fix:
----
Also retrieve moves whose source and destination are both inside the aggregate replenishment-location set.

Include these internal moves in both the incoming and outgoing grouped queries. The existing per-location path filtering then assigns each side correctly:

- the source replenishment location counts the move as outgoing;
- the destination replenishment location counts it as incoming.

For the reported transfer, this produces:

    Stock:
    0 on hand + 0 incoming - 3 outgoing = -3

    Replenish Location:
    0 on hand + 3 incoming - 0 outgoing = 3

This is correct because the report creates replenishment propositions per location, even though the initial move query is performed for all replenishment locations together.

---

opw-6462608


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

Forward-Port-Of: odoo/odoo#282168

Steps to produce:
---
- Install the `website_sale_loyalty` module.
- Navigate to Discount & Loyalty and create a new coupon program.
- Keep the existing `10% Discount reward` and add a second reward
  of type `Free Product`. Select a product for the free product reward.
- Generate a coupon and set its balance to `2` coupon points.
- Open the website and add a product to the shopping cart.
- Apply the generated coupon code.
- Attempt to redeem both rewards (the 10% discount and the
  free product reward) using the same coupon.

Issue:
---
- When trying to apply the second reward, it shows `This program is already applied to this order.`

Root cause:
---
- Once a program was applied to the order, subsequent rewards from the same program were blocked, regardless of whether the customer had enough points to claim them.

Solution:
---
- If a reward from an already-applied program is still claimable (i.e, the customer has sufficient points), allow it to be applied to the order.

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

Bug:
	- Create a working sched were one day has less working hours than the rest.
	- when generating a payslip for an employee linked to that working sched , you'll have half-day attendances even though he worked all his days

Reason :
	- in _get_work_hours_split_half , when building work_data, we compare the duration worked by the employee that day not against the contractual amount of that that but instead we use self.resource_calendar_id.hours_per_day or the max hours per day on that working day , so the day with the least contractual hours on that working sched for exemple will fail this condition " float_compare(duration_sum, number_of_hours_full_day, 2) != -1" even if the employee worked that whole day. 

Fix:
	- for fixed scheds : we builed hours_per_dayofweek where we store the hours for each day of the week , later on , we check the weekday and retreive the corresponding official working hours on that day.
	- for variable scheds: because in this case each day can have its own officil working hours , we fetch the official hours of a certain date right before the logic that determines if it's a full or half a day.

task - 6377396

Forward-Port-Of: odoo/enterprise#124100

Steps to reproduce
---
1. In Settings > Technical > Email > Alias Domains, create an alias domain (e.g. `example.com`).
2. Open the ECO Types configuration, pick a type (e.g. "BOM Updates"), and set its Email Alias to `bom-updates`.
3. Send an email to `bom-updates@example.com` with any subject and body.
4. The gateway fails to open the change order: the sender receives a bounce and no `mrp.eco` appears under that ECO type.

Issue
---
`product_tmpl_id` on `mrp.eco` is defined with `required=True`: https://github.com/odoo/enterprise/blob/79f9ff2ccea3153c457e286bbbca27794ccfdb57/mrp_plm/models/mrp_eco.py#L261-L266

That constraint was added by ac635694 ([IMP] mrp_plm: ux improvements), which tightened the form UX but did not account for the mail gateway, which opens change orders without a product.

A change order can be created from an incoming email: the alias declared on `mrp.eco.type` routes the message to `mrp.eco`, and `_alias_get_creation_values` injects only `type_id` into the creation values:
https://github.com/odoo/enterprise/blob/79f9ff2ccea3153c457e286bbbca27794ccfdb57/mrp_plm/models/mrp_eco.py#L55-L61

The gateway then builds the record with `message_new`, called from `_message_route_process`: https://github.com/odoo/odoo/blob/c6ef99510adcb079f34657aa66dcf191928e3355/addons/mail/models/mail_thread.py#L1553-L1575 https://github.com/odoo/odoo/blob/c6ef99510adcb079f34657aa66dcf191928e3355/addons/mail/models/mail_thread.py#L1402-L1413

An email carries no product, so those creation values have no `product_tmpl_id`. `required=True` is enforced only by the database `NOT NULL` constraint, so on any database where that constraint is present the gateway `create` raises and the incoming request is lost. A product is not actually needed until the change order starts its revision, where `product_tmpl_id` is first read to copy the BoM and gather its documents: https://github.com/odoo/enterprise/blob/79f9ff2ccea3153c457e286bbbca27794ccfdb57/mrp_plm/models/mrp_eco.py#L755-L777

opw-6351438

Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

Forward-Port-Of: odoo/enterprise#128876
Forward-Port-Of: odoo/enterprise#109010

Steps to reproduce
---
1. Enable Storage Locations and Lots/Serial Numbers.
2. Set the delivery operation type's "Source Location" to "Do not scan".
3. Create a serial-tracked product with a serial stored in a sublocation (e.g. WH/Stock/Section 2).
4. Confirm a sale order for it, open the delivery in Barcode, and scan an unreserved serial.

Issue
---
Scanning the unreserved serial creates a new move line that falls back to _defaultLocation() because the decoded scan carries no source location (the operation type does not require scanning one) and never carries the serial's quant location.

https://github.com/odoo/enterprise/blob/f42cfa7265ce32bd95f7f805cf4fb54d8b79cce1/stock_barcode/static/src/models/barcode_model.js#L937-L944

For a delivery, that default resolves to the picking's own source location (the parent WH/Stock), so the line is sourced from the parent instead of the sublocation where the serial physically sits.

https://github.com/odoo/enterprise/blob/f42cfa7265ce32bd95f7f805cf4fb54d8b79cce1/stock_barcode/static/src/models/barcode_picking_model.js#L1542-L1544

On validation the unit is deducted from the parent location instead of the sublocation, leaving a stale quant of the serial in the sublocation and a negative quant at the parent.

opw-5864414

Forward-Port-Of: odoo/enterprise#128523
Forward-Port-Of: odoo/enterprise#121375

Steps to reproduce:
- send an image in a Discuss channel
- click the image to open the file viewer
- click the download button

=> Android shows "The Odoo Mobile Apps only supports file downloads
   using the HTTP protocol."

downloadFile()'s GET-by-URL case fetches the URL via XHR, then saves the Blob response by clicking a hidden <a download> anchor on a blob: URL. Android's DownloadManager only accepts http(s) URLs, so it rejects that blob: URL instead of downloading anything.

Patch downloadFile._download to hand the URL directly to a new mobile.methods.saveFile bridge method when available, the same way download._download already delegates to mobile.methods.downloadFile.

Blob/string content downloads aren't handled here — the only such call site (spreadsheet JSON export) is debug-mode only, so this is left as a console.warn for now.

Related to odoo/odoo@e83fd8c08c879f5e262d39f24edcb3f81238ea82

Code made by Claude
Changes supervised by HUVW

Forward-Port-Of: odoo/enterprise#128471
Forward-Port-Of: odoo/enterprise#127693

Steps to reproduce:
---
- Install `website_sale` module.
- Enable `Product Variants` and `Prevent Sale of Zero Priced Product` in settings.
- Create new attribute > set `Variant Creation` as `Never` and also add value with extra price.
- Create a product with sales price = 0, assign the attribute, and publish it.
- As a public user (incognito), try to add the product to the cart.

Issue:
---
- In terminal error `The given product does not exist therefore it cannot be added to cart` is raised.

Root cause:
---
- In `_is_add_to_cart_allowed()`[1], the method calls `_get_contextual_price()` [2] to check if the product's price is zero when `prevent_zero_price_sale` is enabled.
- However, `_get_contextual_price()` is called without the no-variant attribute values in the context, so it does not account for their `price_extra`. For a product with list price as 0 and attribute with extra price, the price is incorrectly computed as 0, causing `_is_add_to_cart_allowed()` to return `False`.

Solution:
---
- Before calling `_is_add_to_cart_allowed()`, set the product's context with the no-variant attribute values via `_get_product_price_context()`, so that `_get_contextual_price()` correctly includes the price extra in its computation.

[1]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/controllers/cart.py#L117-L120

[2]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/models/product_product.py#L149-L150

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

Forward-Port-Of: odoo/odoo#283491
Forward-Port-Of: odoo/odoo#278620