To be able to compute the taxes offline, the POS JS code mimicked the `compute_all` function in `account_tax.py`. At some point, the POS added an extra field on `account.tax` (see:
https://github.com/odoo/odoo/commit/8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9): `real_amount` which is defined as:
    real_amount = tax.amount * sum(tax.repartition_line.factor)
Then, when fetching the data from the server to the client, the `real_amount` was passed in place of the `amount`.

But then, the `amount` field in the JS is no longer the same as in the python code and it is very error prone. In addition, it's easy to get rid of this extra field by using the sum of the factors from the repartition lines.

Now, we pass the sum(tax.repartition_lines.factor_percent)/100, which is equivalent to sum(tax.repartition_line.factor) to the client, and use it in the `compute_all` as done in the python function, and leave `tax.amount` untouched.

Both `compute_all` functions now operate using the same `tax.amount` and we get rid of the `real_amount` field.

upgrade-https://github.com/odoo/upgrade/pull/4307

Description of the issue/feature this PR addresses:

We have a client with a database where the number of account.payment records now exceeds 150k. 

The account.chart.template existing_accounting method has extremely poor performance, causing Settings app not to load.

No amount of ANALYZE seems to make any difference.

By adding an explicit order to the queries within `existing_accounting` the PostgreSQL query cost drops to `cost=0.84..1.78 rows=1 width=4` from `cost=13061.20..18895.19 rows=1 width=24` (on my local dev machine).

Query plan after:
```
devel => EXPLAIN SELECT "account_payment".id FROM "account_payment" LEFT JOIN "account_move" AS "account_payment__move_id" ON ("account_payment"."move_id" = "account_payment__move_id"."id") WHERE ("account_payment__move_id"."company_id" = 1) ORDER BY  "account_payment".id DESC LIMIT 1;
                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.84..1.78 rows=1 width=4)
   ->  Nested Loop  (cost=0.84..143789.87 rows=154031 width=4)
         ->  Index Scan Backward using account_payment_pkey on account_payment  (cost=0.42..6559.15 rows=154031 width=8)
         ->  Index Scan using account_move_pkey on account_move account_payment__move_id  (cost=0.42..0.89 rows=1 width=4)
               Index Cond: (id = account_payment.move_id)
               Filter: (company_id = 1)
```

Query plan before:
```
devel => EXPLAIN SELECT "account_payment".id FROM "account_payment" LEFT JOIN "account_move" AS "account_payment__move_id" ON ("account_payment"."move_id" = "account_payment__move_id"."id") WHERE ("account_payment__move_id"."company_id" = 1) ORDER BY  "account_payment__move_id"."date" DESC,"account_payment__move_id"."name" DESC  LIMIT 1;
                                                                               QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=13061.20..18895.19 rows=1 width=24)
   ->  Nested Loop  (cost=13061.20..898628048.52 rows=154031 width=24)
         Join Filter: (account_payment.move_id = account_payment__move_id.id)
         ->  Gather Merge  (cost=13061.20..110741.84 rows=308506 width=24)
               Workers Planned: 2
               ->  Incremental Sort  (cost=12061.18..74132.57 rows=128544 width=24)
                     Sort Key: account_payment__move_id.date DESC, account_payment__move_id.name DESC
                     Presorted Key: account_payment__move_id.date
                     ->  Parallel Index Scan Backward using account_move_date_index on account_move account_payment__move_id  (cost=0.42..57930.86 rows=128544 width=24)
                           Filter: (company_id = 1)
         ->  Materialize  (cost=0.00..5366.47 rows=154031 width=8)
               ->  Seq Scan on account_payment  (cost=0.00..3994.31 rows=154031 width=8)
```

Current behavior before PR:

Settings app will not load.

Desired behavior after PR is merged:

Settings app loads.

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

CLA PR: https://github.com/odoo/odoo/pull/112468

Forward-Port-Of: odoo/odoo#112470

When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines. 
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.

Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN' 

This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.

The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.

opw-3127690

Forward-Port-Of: odoo/odoo#112692

This commit fixes an issue where the "No records found" helper text is
wrongly positioned below the sample data's records (i.e. not visible)
instead of over them.

This is basically a revert of https://github.com/odoo/odoo/commit/9407383a569711651182a3d0bebd2f990677e53f
due to the changes in the DOM and styling made in the meantime.

But actually we can go further and ensure we always have the ListView's
table present in the DOM. This change allows to simplify the positioning
of the helper and the implementation of the Purchase's dashboard.

Steps to reproduce:
- create a new database **without demo data**
- install "Planning" and "Sales" apps
- with a mobile-like screen size, open Planning
- switch to Gantt view
- in a cell, click/tap on the magnifier button (which is on hover...)
- the many2x view doesn't contain data
=> action helper "No records found" isn"t visible (scroll to bottom to
find it)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#112626

Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR" for the default calendar used by the company.

Issue:
A ValidationError appears: 'Attendances can't overlap.'

Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.

When we want to switch from a one-week schedule to a two-week schedule, we first delete the attendances from the schedule to be modified. However, if this schedule is the company's default schedule, it will no longer have the default attendances
that we must use to build the two-week schedule.

So we end up with the two "fictitious" attendances that are used to delimit the two weeks.

With only these two attendances, the constraint of not having two overlapping attendances is not respected
(because the two attendances created will be modified to belong to the same week).

Solution:
Check that the calendar to be modified
is not the default calendar used by the company.

opw-3127337

Forward-Port-Of: odoo/odoo#111559

## Current behaviour
When creating a custom menu that wants to display the list view of the `approval.product.line`, we get a stack trace about the lack of a "parent" field.

## Expected behaviour
Should not have a stacktrace when creating a custom list view of `approval.product.line`.

## Steps to reproduce
- Install Approvals and Studio
- Create a custom menu with Studio based on the existing model `approval.product.line`
- Open the new menu -> stacktrace

## Reason for the problem
By default, the view for `approval.product.line` is a view that is embedded by default, therefor in the domains for the attribute we use the "parent" field to reference to the "parent" view js-side. But when creating a menu via Studio, this assertion is not correct anymore, since the view is not embedded.

## Fix
Create a separate list view for the model with a higher priority, so that studio takes it when creating the view. Also remove the attributes, since the fields don't exist on the model and we can't find their value from the "parent", since it doesn't exist.

## Affected versions
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- master
---
opw-3164422

Forward-Port-Of: odoo/enterprise#37027

Hong Kong Payroll Localisation

Features:

- Add Working Times to include Weekend in the payslip to calculate Daily Wage
- Add Payroll Structure for full time employee, including
  - Monthly Salary (CAP57)
  - Payment in Lieu of Notice
  - Long Service Payment
  - Severance Payment
- Add Salary Rules
  - MPF
  - 713 computation gross
  - AutoPay or Second Batch AutoPay amount
  - End of year payment
- Add Leave Types
- Add Work Entry Types
- Add Payslip Other Inputs (e.g. Back Pay, Commission, etc)
- Add Rules parameter (e.g. MPF Threshold, MPF Maximum, etc)
- Allowance
    - Internet Allowance
    - Renting Allowance
- Leave can bypass work entry type such that some leaves can override public holiday or weekend.
- New fields under employee to calculate MPF Volunteer Contribution  
- Daily Wage calculation will compare 713 daily wage or monthly daily wage is larger to decide to use which wage
- 713 Computation
  - Use past 12 months payslip divided by work day to calculate the daily wage (Only use those work day which is full pay)
- If taking leave and the leave start day is from last month, the leave daily wage should use the first day of the leave.
- Add new fields, 713 Gross, MPF Gross, AutoPay Gross, Second AutoPay Gross in Payroll Report

Related: https://github.com/odoo/odoo/pull/112066

task-2455248

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

Forward-Port-Of: odoo/enterprise#34173

## Current behaviour
If a user that doesn't have any access to contracts, adds a task in the gantt view and assigns an employee on it, he gets an Access Error for trying to access hr.contract, but the task is created nonetheless.

## Expected behaviour
Should not get an Access Error, because the task gets added anyway, and you can add the task from the list view without any problem. (the issue is only on the gantt view).

## Steps to reproduce
- Install hr_timesheet, contracts (not attendance)
- On a user, remove all access rights that are HR related, timesheet rights should be `access to all employee timesheets` (not admin)
- Create a new project as admin
- Login as the other user
- Go to your new project, gantt view, magnifying glass, create/new, assign another user on the task, save it
- You get an access error for the model `hr.contract`.

## Reason for the problem
When computing the schedule for the task, we need to evaluate the working calendar, which internally makes a few searches on `hr.contract`, which the current user doesn't have access to.

## Fix
Add a few strategic `sudo()` in `project.task` to ignore the access requirements for the contracts. This way the client is not forced to grant contract access to a user which schedules task and assigns to other employees on the gantt view.

## Affected versions
- 16.0
- saas-16.1
- master
---
opw-3142948

Forward-Port-Of: odoo/enterprise#36940

## Current behaviour
When setting the discount on an upsell manually, and then confirming the upsell, the discount value was reset at the value it was when creating the upsell.

## Expected behaviour
Should be able to set the discount on the upsell manually and it should be kept that way, not being reset.

## Steps to reproduce
- Install Subscriptions
- Create a subscription, confirm it, invoice it, upsell it
- Take note on the discount value
- Change the discount manually, save it (should stay changed to what you set)
- Confirm the upsell, notice that it reverted back to the value we've taken note on.

## Reason for the problem
Since the discount is a precomputed field, when we confirm the upsell,
a new `next_invoice_date` is computed, which triggers the compute of the
discount, which overwrite the manually set value.

## Fix
We remove the dependency on `order_id.next_invoice_date` on `_compute_discount`,
to prevent the computation when we confirm the upsell.

## Affected versions
- 16.0
- saas-16.1
- master
---
opw-3068419

Forward-Port-Of: odoo/enterprise#37110
Forward-Port-Of: odoo/enterprise#36929