Issue:
----------------------------------------
When having calendar attendances with the "Parental Time Off" work entry type, then the time off calendar view doesn't show these days as greyed out even though it should.

Steps to reproduce:
----------------------------------------
- Install l10n_be_hr_payroll and be on a Belgian company
- Have an employee with a contract
- In the Payroll tab define a start date and an end date for the contract.
- In "Working Hours", create a new working schedule where the Work Entry Type is either Parental Time Off (Belgium) or Time Credit for all five weekdays.
- Click the "Time Off" smart button
- The days covered by the contract aren't greyed out

Cause:
----------------------------------------
`_work_intervals_batch` only subtracted the Parental Time Off/Credit Time attendances when `r and not r._is_flexible()`. `_get_unusual_days` never sets `resources_per_tz`, so `r` is always the empty placeholder resource, which is falsy, so the subtraction never ran.

Solution:
----------------------------------------
Subtract unless `r` is an actual flexible resource, instead of only when it is a non-flexible one.

Note:
----------------------------------------
Not reproducible as of saas-19.3: hr_work_entry's ResourceCalendar gained its own generic `_work_intervals_batch` override there that subtracts any attendance whose work entry type has `count_as == 'absence'`, with no flexible-resource guard. Parental Time Off/Credit Time already have `count_as == 'absence'`, so that override masks this bug by excluding them first. This fix is still needed to make the l10n_be-specific logic correct in its own right.

opw-6397416

Steps to reproduce
1. In Inventory Settings, enable Lots & Serial Numbers and Expiration Dates.
2. Create a storable product tracked by lot with Expiration Date enabled.
3. Create and confirm a dropship of it, then open the move's Detailed Operations.
4. The pre-filled line works: typing a batch and an expiration date creates exactly that lot at validation.
5. To split the quantity, click "Add a line": it opens the "Pick From" popup, and choosing "Create" there creates the lot and attaches it to the line.
6. On that line, edit "Lot/Serial Number" and "Expiration Date", then Validate.

-> Expected: the values entered on the line are used.
-> Actual: they are ignored; the lot created through "Pick From" is delivered with its own expiration date, the name and date typed on the line have no effect.

Issue
---
On a create-lots-only non-incoming operation like `Dropship`, `show_quant` is derived from `picking_code` alone, so the "Pick From" quant picker is shown even though the operation only
creates lots. Adding a line goes through "Pick From", which creates the lot and attaches its `lot_id` to the move line; from then on the line's `lot_name` and `expiration_date` stay
editable but do nothing, since a set `lot_id` is used as-is at validation and the `expiration_date` is recomputed from the lot, so anything typed there is silently dropped. Such an
operation has no existing stock to pick from, so `show_quant` is now gated on the lot settings too: "Pick From" is hidden and the line's `lot_name` and `expiration_date` become the only
inputs, created into the lot at validation like receipts already do.
https://github.com/odoo/odoo/blob/68dcb950df83d70ff2aea0e05c96cc9b57c1a8a9/addons/stock/models/stock_move.py#L646-L647

opw-6530563

Forward-Port-Of: odoo/odoo#290071
Forward-Port-Of: odoo/odoo#287474

Currently, an error occurs on clicking on the graph or the pivot cell if the data is grouped by Employee/Manager/Department.

### **Steps to reproduce**
1) Install helpdesk_timesheet with demo data
2) Go to Timesheet > Reporting > Ticket Analysis
3) Set group by to Employee
4) Click on any graph bar or pivot cell

### **Error:**
`ValueError: Invalid field helpdesk.ticket.employee_id in condition ('employee_id', '=', 1)`

Root Cause:
The `helpdesk.ticket.report.analysis` model includes specific fields such as `employee_id`, `department_id`, and `employee_parent_id` (see [1]) that are defined for reporting purposes but do not exist on the `helpdesk.ticket` model. When a user clicks a data point to view related tickets, the reporting view passes the current domain directly to the ticket list view. Because `helpdesk.ticket` lacks these fields, the ORM fails to validate the domain, resulting in a server error.

[1]- https://github.com/odoo/enterprise/blob/8d16b647431985dd7c216ae39eea6ca050e04b46/helpdesk_timesheet/report/helpdesk_ticket_report_analysis.py#L15-L17

### **Fix:**
This commit introduces a mixin to intercept the openView call. The mixin maps reporting-specific fields to valid relational paths on the ticket model `(for example, employee_id is transformed into user_id.employee_id)`. This ensures that the domain generated from the report model is compatible with the target ticket model.

**opw-5931273**

Forward-Port-Of: odoo/enterprise#108503

**Steps to reproduce:**
- Set preferences to dark mode
- Create a quotation and add a product with optional products (e.g customizable desk) -> Background of optional products is lighter than the surrounding div

**Behavior:**

The `div` showcasing optional products is set to be a bit darker to add contrast in the modal. In light mode, table's background is transparent, which allows it to adapt to a darker container. 
However, this is not the case in dark mode, which causes a mismatch between table and div backgrounds.

By default `$table-bg` follows `$body-bg`:
https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_variables.scss#L738-L740 And is later set to transparent here:
https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/src/scss/bootstrap_overridden_frontend.scss#L74-L75

However when darkmode is enabled, `$body-bg` is re-assigned, which forces `$table-bg` back to the default dark color, bypassing the transparent override. https://github.com/odoo/odoo/blob/3442814d57cd9420d7dc6d022d15cd5d1b3def74/addons/web/static/lib/bootstrap/scss/_root.scss#L132-L139

---

This commit ensures that `table-bg` is explicitly set to transparent for tables displaying optional products.

opw-6569713

Forward-Port-Of: odoo/odoo#288127

[FIX] account_reports: KPI provider: properly ignore inactive returns

Returns can be archived (setting the 'active' field to False) from the UI, so that the user can hide them when not needed, without risking them being regenerated by the cron, and without havin to mark them as completed, which could give misleading information when browsing the history.

The problem was here the KPI provider did not properly ignore such returns.


========================================


[FIX] account_reports: make KPI provider test with existing data in db

The KPI provider query completely ignores multi-company. Because of that, the test wasn't properly sandboxed, and could fail if any non-test company of the database contained a return made from any untested return type, as it would add one element to the result of get_account_reports_kpi_summary.

We now make sure to archive all existing returns, whatever their company, before running the test.

Forward-Port-Of: odoo/enterprise#131438