# How to reproduce
- Go to Inventory > Settings > Operation Types
- Pick any Operation and disable "Allow extra product"
- Create a picking for that operation type with atleast one product and click on "Mark as Todo"
- Go to the Barcode app and find the created picking
- Scan all the reserved products
- Exit the picking and re-enter

# The problem
The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to

# Cause of the issue
The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products).

`_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true :
https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43

So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails.

# Proposed Solution
Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation`

opw-6231238

Forward-Port-Of: odoo/enterprise#118378

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#122126
Forward-Port-Of: odoo/enterprise#119530

The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set.

When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload.

unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records.

Steps to reproduce:
1. Open the Knowledge app
2. Create an article with two child articles
3. Add one of the two children to your favorites with the star icon
4. Open another article that is not under that parent
5. Fold the parent article in the sidebar, then refresh the page
6. Expand the parent article

=> only the favorited child is shown under the parent, the other child is missing

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

Forward-Port-Of: odoo/enterprise#118804

Currently when a shopfloor operator modifies the operator, operator images are not visible and only place holder images are visible.

## Steps to produce:
- Install Manufacturing with demo data
- Login as Marc Demo
- Open shopfloor

## Observed Behavior:
Operator is unable to see their own profile picture and when you press the Edit Operator the operator is not able to see their as well as other operators images as well.

## Root cause:
This issue occurs because by default an operator's user does not have access right for `Employees` in Human Resources section as they are not an HR officer nor an administrator.

So when the user tries to access the image url that is meant for users with those access rights (HR officer / Administrator) at [1] and at [2].

The system returns a placeholder image instead of the employee image since the operator does not have access to hr employee model but does have access to hr employee public as per this [commit](https://github.com/odoo/odoo/commit/c9ca3761464413327d2beb697553a3ccd7eef4d1)

[1]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/dialog/mrp_employee_dialog.js#L16 
[2]-
https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/employees_panel.xml#L9-L10 

## Solution:
Allowing operators to see images can be done by modifying the links to use the public model instead of the private model.

This will allow operators see other operators based on images and should improve user experience.

| Before |
|--------|
| <img width="1865" height="844" alt="image" src="https://github.com/user-attachments/assets/c28f4209-0a60-486a-bfec-2a4db39cd946" /> |
| <img width="995" height="899" alt="image" src="https://github.com/user-attachments/assets/7541edd9-6cc9-42d1-b5c5-39e0740d9a93" /> | 

| After |
|--------|
| <img width="1881" height="903" alt="image" src="https://github.com/user-attachments/assets/df3f8357-5cc2-4688-83dd-9a009fd56957" /> |
| <img width="1221" height="862" alt="image" src="https://github.com/user-attachments/assets/c9d72b07-e1ad-43e4-85f5-00d8f1db9095" /> | 



opw-6321989

Forward-Port-Of: odoo/enterprise#123540
Forward-Port-Of: odoo/enterprise#121751

Steps to reproduce:
1. Install eCommerce and Subscriptions.
2. Create a 21% Excluded tax.
3. Create a subscription product with a price of 45 with 21% tax and enable "Accept One-Time" in the Recurring Prices tab.
4. Publish the product on the website under the Sales tab.
5. Create a pricelist for 6 months recurring with two lines:
 - If min quantity is 0, then 0% discount
 - If min quantity is 2, then 5% discount
6. Set "Display Product Prices" to "Tax Included" in the Settings.
7. Open the product on the website, select the 6-month plan, and increase quantity to 2.

Issue:
The discount percentage displayed on the website shows 4% instead of the configured 5%.

Why this happens:
In `_get_additionnal_combination_info`, the discount is reverse-calculated from the tax-included price vs the tax-included sales price. When the 21% tax is included to both prices, it introduces a floating-point precision loss (4.9954..%), which floor() then truncates to 4%.

Fix:
When the pricelist rule uses 'percentage' discount, read `percent_price` directly from the pricing rule instead of reverse-calculating from tax-adjusted prices, as it represents the exact discount percentage the merchant configured with no floating-point involvement.

opw-6224735

Forward-Port-Of: odoo/enterprise#121654

Steps to reproduce:
1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya.
2. Sell and validate an order.
3. Refund it from the POS and validate the refund order.

Issue:
- A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`.

Cause:
- When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call.
- The same multi-id list is also produced whenever several orders created offline get synced together once back online.

Solution:
- `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list.
- Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case.

opw-6364221

Forward-Port-Of: odoo/enterprise#123043

**Commit 1:  [FIX] account_reports: warning for CTA visibility**
Steps to reproduce:
- Open the balance sheet

-> The warning for CTA is displayed even when a single company is selected.
It should only be the case if multiple companies having different currencies
are involved in the computation of the report.

**Commit 2: [FIX] account_reports: hide groupby field on form view for composite report**
this field is useless for composite reports.

**Commit 3: [FIX] account_reports: differentiate UX for auditable external values.**
When creating a budget in the P&L, the external value cells should not be
auditable. The data was properly set but not the templates.

**Commit 4: [FIX] account_reports: avoid traceback on double-click on warning**
Steps to reproduce:
- Open an accounting report with any warning banner ("draft entries" for example)
- Quickly double-click the delete cross button

-> traceback stating that it cannot read properties of null (reading 'remove').

**Commit 5: [FIX] account_reports: working file card style adjustments**
<img width="401" height="317" alt="image" src="https://github.com/user-attachments/assets/76f636f0-09d8-44e5-8c7c-37561dc00b10" />


task-6361495

Forward-Port-Of: odoo/enterprise#123004

Steps to reproduce:
- Create one user linked to two companies.
- Create one employee per company for that user.
- Select one company and approve a time off for the employee.
- Open Tasks > Gantt and create a task during the approved time-off period the warning is shown and the Gantt cell is grayed out.
- Select both companies and create a task during the same time-off period in Tasks > Gantt.

Issue:
When multiple companies are selected, the time-off warning is still displayed but the corresponding Gantt cells are no longer grayed out, leading to an inconsistency between the warning logic and the Gantt rendering.

Cause:
In multi-company setups, a user can be linked to multiple resources. The Gantt unavailability logic assumed a one-to-one relationship between user and resource causing unavailability intervals from some resources to be overwritten.

Solution:
Aggregate unavailability intervals from all resources linked to the same user, limited to the selected companies, and merge them with the company calendar unavailability to ensure consistent Gantt gray rendering.
Related PR: https://github.com/odoo/enterprise/pull/57028

task-5089385

Forward-Port-Of: odoo/enterprise#123732
Forward-Port-Of: odoo/enterprise#105288

Steps to reproduce:
------------------------------------
1. Install the Knowledge module.
2. Open any article.
3. Click the header icon. If no icon is present, add one from the Actions menu.
4. Click the header icon again.
5. Click Remove icon from the emoji picker.

Observation:
------------------------------------
A traceback is raised when removing the header icon. 
```
TypeError: Cannot set properties of undefined (setting 'scrollTop')
```

Issue:
------------------------------------
The emoji picker component updates its scroll position through a grid reference.

After this PR - https://github.com/odoo/odoo/pull/269588, the emoji picker was migrated to Owl 3, which changed the way component references are handled. The header icon removal flow still uses the previous ref access pattern, causing the grid reference to be `undefined` when attempting to update `scrollTop`, resulting in a traceback.

Solution:
------------------------------------
Update the syntax for accessing the ref signal.

Forward-Port-Of: odoo/enterprise#123880

`useLayoutEffect` is deprecated in OWL3. This replaces it with `useEffect`
and moves the vertical-positioning logic into a `threadTops` getter.

Two `useLayoutEffect` calls existed: one ran a batched vertical-dimension
computation on `activeThreadId` change, the other a debounced horizontal
computation on `editorThreads` change.

- Horizontal: kept as a `useEffect`. Where the old hook ran on every patch,
  the OWL3 effect only reacts to the values it reads, so it reruns just when
  threads are added or removed.
- Vertical: the positions can simply be derived while rendering, so the logic
  moved into a `threadTops` getter used by the template. This lets the render
  react to the relevant state on its own and drops the post-patch hook.

The refactored code has test coverage — these failed when the effect was
commented out and now pass:
- TestESLint.test_eslint (`activeThreadId` defined but never used)
- TestKnowledgeArticleTours.test_knowledge_article_comments (comments UI broken)
runbot build with the effect commented out: https://runbot.odoo.com/runbot/batch/2594694/build/114736755