## Problem
When dragging the edge of a scheduled workorder to change the start or end time, _web_gantt_move_candidates would throw a traceback. This is because the web call only supplies the new time chosen by the drag+drop. That is, if date_end was changed, date_start wouldn't be present, so accessing the missing field directly triggers a KeyError. This also revealed a secondary issue involving dependent tasks, where if the parent task is rescheduled with the pills, the child task would fail to find candidate reschedule dates (since its only dependency is being moved), and no boundary date would be supplied when calling _web_gantt_reschedule_compute_dates. This led to another traceback.

## Solution
For the first issue, we will get the start date and end date from the supplied values more safely, using get() to default to the original start/end. For the second issue, if the boundary date isn't found by _web_gantt_get_first_and_last_possible_dates, we fall back to the candidate's existing start or end date.

## Steps to replicate (Runbot saas-19.4)
1. Create a product with a BOM with 2 operations on the same workcenter
2. Create an MO for this product, confirm it, and plan it
3. Head to Manufacturing > Planning > Work Orders / Planning
4. Try to change the end date of the first work order by dragging the edge of the pill

opw-6378769

Forward-Port-Of: odoo/enterprise#124710

Currently, an error occurs when a user sets an employee on a payslip.

**Steps to Reproduce:**

 - Install `l10n_hk_hr_payroll` with demo data.
 - Switch to the `Hong Kong` company.
 - Create an `employee` and make sure that the employee's version has no `contract start date`.
 - Go to `Payroll` > `Payslips` > `Payslips`.
 - Create a `payslip` and set that employee.

`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

When a user sets an employee on a payslip, the system computes the worked day lines [1]. 
If the salary structure uses worked day lines, it creates the corresponding records [2] and 
calculates out days and out hours based on the contract dates.
During this process, the payslip dates are compared with the version's contract start date. 
If the version does not have a contract start date, it raises an error [3].

This commit ensures that the payslip dates are compared with the version's contract start date, 
and that out days and out hours are calculated only when the contract start date exists. Cases 
where no contract start date is defined are already handled in payslip [4].

[1]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1964

[2]: https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1985-L1988

[3]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/l10n_hk_hr_payroll/models/hr_payslip.py#L309

[4]- https://github.com/odoo/enterprise/blob/03787659236cbcb46c27acebf410ee3d1e9eb15c/hr_payroll/models/hr_payslip.py#L1092-L1096

sentry-7632216317

Forward-Port-Of: odoo/enterprise#120234

Currently, when a quotation is created from a repair order generated from a helpdesk ticket, 
the salesperson is not set on the quotation even if the customer has a salesperson assigned.

**Steps to Reproduce:**

 - Install `helpdesk_repair`.
 - Go to `Helpdesk` > `Configuration` > `Helpdesk Teams`.
 - Open a team recod and enable `Repairs`.
 - Create a `contact/customer` with a `salesperson` assigned.
 - Go to `Helpdesk`, create a ticket for that `customer`, and select the `helpdesk team` 
   configured above.
 - Click `Repair`, then click `Create Quotation`.
 - Open the quotation and check the `Salesperson` field in the `Other Info` tab.

**Current behavior:**
The Salesperson field on the quotation remains empty.

**Expected behavior:**
The Salesperson field on the quotation should inherit the salesperson assigned to the 
selected customer/contact.

**Cause of the issue:**
When a repair order is created from a helpdesk ticket, default_user_id [1] is passed in the context . 
This value is propagated when creating the repair order [2] . Later, when creating the quotation from 
the repair order [3], the same context is reused.
Because default_user_id is already present in the context, it overrides the precomputation of user_id 
from the customer. As a result, user_id is initialized with an empty value and remains unset.

**Fix:**
This commit ensures that default_user_id is removed from the context before creating the 
sale order. Without a default value for user_id, the field is correctly precomputed from the 
selected customer, and the salesperson is properly assigned.
[1]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L52

[2]- https://github.com/odoo/enterprise/blob/2662932c7ac8ebf3ed5a05d44d7ebfaff869fcbd/helpdesk_repair/models/helpdesk_ticket.py#L36-L40

[3]: https://github.com/odoo/odoo/blob/29328b8fccff833c14de317b51f3b4e5a8c40f75/addons/repair/models/repair.py#L357

opw-6344939

Forward-Port-Of: odoo/enterprise#126310
Forward-Port-Of: odoo/enterprise#122980

**Steps to reproduce:**
- Go to CRM app as an internal user (non-admin)
- Click on Generate button
- Can't create leads from business card pictures
- Only setting the user as admin enables it (was working fine in previous versions)

**Issue:**
Dropdown action is restricted to admin only by default using `hasAccess`.
If there is a corresponding model on the `LeadGenerationDropdown` it is later changed according to the current user access rights using `await user.checkAccessRight(model, "create")`.

**Fix:**
Default `hasAccess` to `True` as there is no related model for the lead generation of business cards.
(Note: could also provide the missing model ?)

- Installation should be restricted to the admin.
- Access message should be shown to the user if he doesn't have enough rights to the related model.
- Non-admin users should be able to use the feature if no model is provided and the related app is available.

dropdown: https://github.com/odoo/odoo/commit/978019522746ccb971eeb15c5d9530e438b7d2f3
business card: https://github.com/odoo/enterprise/commit/48a9cba24cb51b11a08dd9c0ff1291e15232260f

opw-6258689

Forward-Port-Of: odoo/enterprise#121682

**Step To Reproduce:**

1. Configure a POS with German Fiskaly (l10n_de_pos_cert), Restaurant, and Kitchen Display (pos_preparation_display).
2. Create a new order in the POS and add the first product.
3. Observe that the order does not appear on the Kitchen Display.
4. Add a second product to the same order.
5. Observe that the order now appears on the Kitchen Display.

**Issue:**

The first product of a new restaurant order is not synchronised with the Kitchen Display when the German Fiskaly localisation is enabled.

**Reason:**

`syncAllOrders()` only processes orders returned by `getPendingOrder()` and ignores orders explicitly passed through `options.orders`. After the initial Fiskaly synchronisation, the order is serialised and removed from the pending queue. Consequently, the Preparation Display synchronisation receives no orders from `getPendingOrder()`, preventing the order from reaching the backend.

**Solution:**

Update `syncAllOrders()` to prioritize the orders explicitly provided through `options.orders`. When `options.orders` is not available, fall back to the existing behavior by synchronizing the orders from `orderToCreate` and `orderToUpdate`.

opw-6321376

Forward-Port-Of: odoo/enterprise#125743

**Problem:**
On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate.

**Steps to reproduce:**
1. Install `website_sale_renting_planning`.
2. Create a planning role with `sync_shift_rental` and one resource.
3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above.
4. Pre-book the resource for some window via a `planning.slot`.
5. From eCommerce, add the product to the cart for the same window.
6. Proceed to checkout/payment.

**Current behavior:**
The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period.

**Expected behavior:**
The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity.

**Cause of the issue:**
`sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but
`website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all.

**Fix:**
Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types.

opw-6247034

Forward-Port-Of: odoo/enterprise#125855
Forward-Port-Of: odoo/enterprise#118943

Once a lock date is set on a company, report lines that look back before a given date, such as a Balance Sheet's "Profits (Losses) from Previous Years", could silently lose data. Any line that gets captured in a snapshot and uses a date scope 'to_beginning_of_*' was affected.

Snapshots are computed on the options of the lock date and stored with their 'date' set to the options' date_to (the lock date). Only 'from_beginning' actually evaluates the accounting up to date_to. The 'to_beginning_of_*' scopes stop right before the period or fiscal year, so the data really aggregated stops earlier than the stored date:

  - 'to_beginning_of_fiscalyear': up to a whole fiscal year earlier.
  - 'to_beginning_of_period': up to a whole period earlier.

When the report is rendered, the engine sums only the moves dated after the snapshot's date and adds the snapshot's data. Everything between the snapshot's real cut-off and its (later) stored date is never counted.

Aim the options at the lock date so each scope's bound falls on it, and store the date really covered(using _get_date_bounds_info()). The snapshot's date then always matches its data, and "to_beginning_of_*" covers the last fiscal year starting before the lock date instead of forcing every later render to rescan it.

Snapshots written before this fix still hold the mismatched date, so the account_codes sub-engine version is bumped to 2 to re-trigger the snapshots generation

opw-6379956

Forward-Port-Of: odoo/enterprise#126542