Step to Reproduce:
- install UAE Payroll localization and attendance
- create employee and running employee contract and give basic salary, housing, transportation and other allowance.
- work entry source should be attendance
- create a payslip and compute sheet.

Issue:
- The values for payslip lines are not as expected.
- The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule.

Reason:
- When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available.

Solution:
- Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule.

task-5270185

Forward-Port-Of: odoo/enterprise#109048
Forward-Port-Of: odoo/enterprise#103282

Problem
------------------
The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display.
Navigation:
1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save
2.  Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save
3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save
4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available

Objective
----------------------
Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet.

Solution
---------------------------
Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed.

Task: 5942461

Forward-Port-Of: odoo/enterprise#109049
Forward-Port-Of: odoo/enterprise#107719

This commit improves the new field service integration and fixes some
mistakes made during the merge of Field Service app inside Planning app.

In this commit,
- the new format duration has been used for allocated hours and break time
  fields in planning,
- some planning.slot fields are hidden in the form view when field service
  integration is enabled to reduce the number of fields inside that view
  since those fields were more useful for a planning manager to prepare
  the intervention of his workers,
- some access right errors are fixed,
- the planning user can no longer edit access once field,
  service integration is disabled,
- field service geolocation service has been re-introduced since it was
  removed when the timer in timesheets has been reviewed,
- some terms are now correctly translated,
- `planning_field_service` module is flagged as an application,
- `Products` menu item has been added in planning field service,
- map and activity views has been been added in all planning menu items
  when field service is enabled.

task-5921961

Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com>

Forward-Port-Of: odoo/enterprise#108363

Steps to reproduce
------------------
1. Install `pos_settle_due`
2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc).
3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0
4. Select the invoice(s)
5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom.

-> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method.

Why the issue
-------------
If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created.

That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions.

After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places:
1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation.
2. On the products screen, when using fast payment, that is fast validation.

For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation.

However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation.

The fix
-------
Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation.

Notes
-----
- We keep the methods in `payment_screen` for backward compatibility, they will be removed in master.
- We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so  it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`.

opw-5488587

Forward-Port-Of: odoo/enterprise#108602
Forward-Port-Of: odoo/enterprise#105660

*: account_asset, sale_lazada

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

opw-5461135
opw-5417749

Forward-Port-Of: odoo/enterprise#107732
Forward-Port-Of: odoo/enterprise#106694

This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated.

The original bug was:
create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium
employee > new > payroll > contract > start_date: any date (this should create a first dimona activity)
settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually

_trigger_l10n_be_next_activities in hr.version of l10n_be_hr_payroll is duplicating Dimona activities on records that already have one.

We check if a dimona activity already exists for a given hr.employee before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it.

related to: [96423](https://github.com/odoo/enterprise/pull/96423)
[tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)

### Problem
Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus
caused MemoryErrors and 80+ second load times on large databases.

### Root Cause
`_read_group_for_accrual` loops over each group result to manually sum
non-stored computed fields. On each iteration it called `search()` with
a domain containing `('invoice_to_be_issued', '=', True)`, triggering
`_get_accrual_line_ids` once per group instead of once per request.

### Fix
Move the `search()` call outside the loop so matching records are fetched
once per request. The per-group partition is then resolved using
`search_fetch` + `grouped`, which handles the field prefetching and
grouping into recordsets in one call.

### Before / After
| Metric                        | Before  | After  |
|-------------------------------|---------|--------|
| Total request time            | 82s     | 8.5s   |
| `_get_accrual_line_ids` calls | 82      | 3      |
| MemoryError on large DBs      | ✓       | ✗      |

opw-5392606

Forward-Port-Of: odoo/enterprise#108102