Versions
--------
- saas-16.3+

Issue
-----
If early pay discount includes taxes, its amount was calculated by first multiplying the total amount by the discount's complementary percentage, and take the difference between its result and the total amount.

Let's assume discount is 10% and total price is 1725.05.
- We want to pay 90% of the full amount, which is 1552.545;
- to get the discount, we subtract it from the full amount:
    1725.05 - 1552.545 = 172.505;
- we then round this discount to 172.51;
- and return total amount minus discount as amount due after discount:
    1725.05 - 172.51 = 1552.54
- elsewhere we round 1552.545 to 1552.55, a 1 cent difference

Cause
-----
The `_get_amount_due_after_discount` adds half a cent to the discount by rounding half-up, while elsewhere the reduced price gets rounded half-up, increasing it by half a cent, this adds up to a 1 cent discrepancy.

Solution
--------
Call the rounding method after subtracting discount from the total amount, so rounding happens in the same direction.

Issue found working on opw-3705546

Forward-Port-Of: odoo/odoo#163786

In iOS, there is a dictation feature accessible from the keyboard. This feature modifies the DOM directly and triggers input events.

From observations made on [1], it seems it triggers each event twice for unknown reason. Since there is custom editor code bound on this event, the `insertText` function  was called twice, thus resulting in the text being duplicated.

Note that the bug is in fact subtle because, if the selection reported by iOS was always accurate when triggering those events, then calling `insertText` twice would have no visual effect. However, in the case where the user chooses to manually stop the dictation mechanism through the dedicated button on the keyboard before it has finished writing the whole sentence, then the selection is not updated accordingly and the second call to `insertText` ends up inserting the text at the wrong place, thus triggering the symptom of duplicating the text.

This commit fixes the issue by restricting the cases where a manual call to `insertText` is needed. The previous comment specified that the only case in which it was needed was when some text was selected. This is not entirely true. The only case in which it is needed is when text is selected in a way that spans multiple block elements, as this is the only case where the browser can alter those nodes by removing or merging them.

Note that the first line of the `insertText` conditional branch, the one that fetches the current selection, actually looks fishy. It is possible the bug is caused by the fact that this selection is used instead of `this._currentStep.selection`. That being said, changing that part of the code in stable would not be worth the risk of breaking something that might rely on it, especially considering the dictation on iOS is a pretty niche feature.

Also note that, for some reason, the issue only happens when the paragraph was empty when the dictation started. If some previous text was already present in the paragraph, for example from a previous dictation test, then the duplication will not occur. In this case however, a traceback can sometimes occur due to the fact that when checking for a potential url match, the `pop` method is called on an array multiple times then the result value is used as an object even though no check were made to make sure that the return value was not `undefined` because the array had nothing more to pop.

This commit fixes that second issue by adding the missing check.

task-3374520
opw-3167676

[1]: https://w3c.github.io/uievents/tools/key-event-viewer-ce.html

Forward-Port-Of: odoo/odoo#163993
Forward-Port-Of: odoo/odoo#160363

It is currently not possible to use a scrapped tracked-by-SN
component in a new MO

To reproduce the issue:
1. In Settings, enable "Multi Locations"
2. Create two products P_finished, P_comp:
    - Storable
    - P_comp tracked by SN
3. Update the quantity of P_comp:
    - WH/Stock: 1 x SN01
4. Process a manufacturing order:
    - Product: P_finished
    - Components:
      - 1 x P_comp
5. Process a repair order:
    - Product: P_finished
    - Remove:
           - Product: P_comp
           - Lot: SN01
           - Destination Location: Virtual Location/scrap
6. Unscrap SN01 (via an internal transfer from scrap to stock)
7. Repeat 4

Error: a UserError is displayed because the SN of the component has
already been consumed. It should be possible to use it

When checking the uniqueness, we are working on the SMLs (see the
lines removed by this commit).
`duplicates` contains the SML from step 4. `duplicates_returned` is
zero since we did not return the component back to the stock.
`removed` is zero too, because we look at the scrapped SML from an
internal location. However, step 5 generates an SML that starts from
the production location. As a result, nothing compensate the value
of `duplicates`, hence the raised error.

Removing the condition of the source location of `removed` would
lead to another bug, so we can't do that. So, this commit suggests a
new implementation based on the following rationale:
- The uniqueness checking simply ensures that one and only one
  existing finished product consumed a specific SN
- What happened outside this context does not matter here

That way, we should only look at the SML from/to production
locations, for tracked-by-sn products used as components only. All
other SML (scrap, unscrap, SML for SN production, and so on) should
not be considered here.

OPW-3834835

Forward-Port-Of: odoo/odoo#164074
Forward-Port-Of: odoo/odoo#163394

Description of the issue/feature this PR addresses:

This commit addresses slow performance of the JS `OrderLine.findAttribute` method when `attributes_by_ptal_id` is exceedingly large.

Before this commit, `findAttribute` would loop over all the values of `this.pos.attributes_by_ptal_id`, and filter out only the attributes that have at least one of the passed in ptal IDs (from the `values` parameter) within the attribute's "values" list. It would also modify the attribute to include a `"valuesForOrderLine"` key mapping to a list of all of the found ptal IDs from that attribute's values.

This method becomes slow when `this.pos.attributes_by_ptal_id` is very large. Since it needs to loop over every single attribute.

This commit provides a workaround to this slowness, by caching the search for valid attributes that this method performs in a lookup table.

First, we construct the lookup table in `_processData` method of the `PosStore` class. `_add_ptal_ids_by_ptav_id` does this, by looping over all the values of all the attributes, mapping the ptav ID of the attribute to all the ptal IDs we find.

Now, inside `findAttribute`, we will instead loop over each of the passed in `values`. For each value, we will retrieve the all the cached ptal IDs from `this.pos.ptal_ids_by_ptav_id` for the given value. Now that we have the ptal IDs, we can get all the corresponding attributes from `this.pos.attributes_by_ptal_id`. For each of those attributes, we can do the same modification from the original method by adding the `"valuesForOrderLine"` key/value. Finally we return all the modified attributes.

This new method has a nested for loop, which may seem like a problem. But I believe that both the things being looped over (`values` and `this.pos.ptal_ids_by_ptav_id[value]`) should be very small compared to the potential size of `this.pos.attributes_by_ptal_id`. (43,000 in this customer's DB)

`findAttributes` is called many times whenever the POS's numpad buttons are pressed, so this commit has the overall effect of drastically reducing the input latency for a numpad press.

However, I do believe that this is a workaround, and the real problem is that the entire `attributes_by_ptal_id` is always passed to the POS, regardless of what products are actually being ordered. `attributes_by_ptal_id` should instead be incrementally fetched as products are ordered (if this is possible).

Benchmarks (in customer DB):

Before commit, each keypad press took around 1-3 seconds per Order Line present in the POS. For 11 products this was ~15 second latency.

After commit, each keypad press is almost instant. The `ptal_ids_by_ptav_id` lookup table will consume additional memory, in this customer's DB I've estimated it to be about 0.3MB more memory. Taking memory snapshots in profiler shows no significant different between versions, however this is inconsistent. Will attach profiler results to PR.

Current behavior before PR:

Poor performance of `OrderLine.findAttribute`

Desired behavior after PR is merged:

Fast performance of `OrderLine.findAttribute` for a memory tradeoff.

opw-3788840

Forward-Port-Of: odoo/odoo#159402

This error arises when the someone clicks on ``Early Discount`` in Payment Terms while creating a new one.

Steps to reproduce
- Install ``account`` module
- Invoicing -> Configuration -> Invoicing -> Payment Terms
- Click on ``New`` -> click on ``Early Discount``

Traceback : 
```
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5848, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.currency()
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1827, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1825, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 739, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 1011, in onchange
    todo = [
  File "addons/web/models/models.py", line 1014, in <listcomp>
    if field_name not in done and snapshot0.has_changed(field_name)
  File "addons/web/models/models.py", line 1127, in has_changed
    return self[field_name] != self.record[field_name]
  File "odoo/models.py", line 6576, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "odoo/fields.py", line 1261, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1443, in compute_value
    records._compute_field_value(self)
  File "odoo/models.py", line 4931, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 100, in determine
    return needle(*args)
  File "addons/account/models/account_payment_term.py", line 95, in _compute_example_preview
    discount_amount = record._get_amount_due_after_discount(record.example_amount, 0.0)
  File "addons/account/models/account_payment_term.py", line 67, in _get_amount_due_after_discount
    discount_amount_currency = self.currency_id.round(total_amount - (total_amount * (1 - (percentage))))
  File "odoo/addons/base/models/res_currency.py", line 217, in round
    self.ensure_one()
  File "odoo/models.py", line 5851, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
  ```

This error occurs from line[1] where the currency ID is getting false within the self, leading to a value error being raised. This happens because of this PR https://github.com/odoo/odoo/pull/161044, where they have removed the default currency from currency ID field.

This commit will fix the above error by adding ``company_id`` field in the payment term from view.

[1] : https://github.com/odoo/odoo/blob/5673ea9d8c6993575bd9ce9c2a931a8738e77e76/addons/account/models/account_payment_term.py#L67

sentry - 5209971284


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

Forward-Port-Of: odoo/odoo#162564

Current Behavior:
-
Creating a copy of a product with attributes and extra prices set for the values of this attribute will not copy the extra prices.

Expected Behavior:
-
These prices should be matched with the newly created objects if possible.

Steps to reproduce:
-
- Create a product > add an attribute line with at least one value.
- Save the product > configure the attribute line and set an extra price for that value.
- Duplicate the product.

Fix:
-
Since copies are not created in cascade by the framework, we need to match by hand the `price_extra` and the `exlude_for` of the newly created `product.template.attribute.value` with the old ones.
As this matching might not be deterministic when the same attribute and value combination is used on multiple lines, we expect that the extra price and the exclusion rule depend only on this combination.

opw-3731192

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

Forward-Port-Of: odoo/odoo#162972
Forward-Port-Of: odoo/odoo#154692

**Current behavior:**
On a payslip, creating multiple lines with the same rule code
will result in a misreport with duplicate pay records.

**Expected behavior:**
Payroll reporting should accurately reflect reality.

**Steps to reproduce:**
1. Create a new salary rule (e.g., Commission) and set its
     'code' field to 'COMMISSION' and tick the option
     `View on Payroll Reporting`

2. Set its 'Condition Based on' to 'Python Expression' and enter
     `result = (inputs.get("COMMISSION") or 0)`

3. Set its 'Computation' to 'Python code' and enter
     `result = (inputs.get("COMMISSION") or 0).amount`
      `result_name = (inputs.get("COMMISSION") or 0).name`

4. Create a `hr.payslip.input.type` (other input type) record
    to permit the newly created salary rule to appear on a
    payslip (e.g., Country of current company and 'Regular Pay'
    for 'Availability in Structure' and 'code' = 'COMMISSION'

5. Create a payslip record (To Pay) for some employee, selecting
     the structure that permits the newly created rule to be
     applied (e.g., 'Regular Pay') (Note the pay period)

6. In the 'Other Inputs' table add two lines both set to the
     'COMMISSION' code -> Compute Sheet -> Create Draft Entry

7. Go to the Reporting -> Payroll -> Pivot View, collapse the
     y-axis; Expand y-axis -> Employee -> Employee from payslip
     -> Add Custom Group -> End Date; Observe multiple entries
     pay period defined when creating the payslip

**Cause of the issue:**
In `hr.payroll.report` these rules will be grouped by their
'total' fields. When we have a repeated rule code with some
'total' amount, we will create two reports for the same
payslip.

**Fix:**
Use a SUM to aggregate these additional_rules in the SELECT and
remove them from the GROUP BY. We need another DISTINCT clause
to ensure we aren't summing redundant row values.

opw-3614679

Forward-Port-Of: odoo/enterprise#60814

**Steps:**
Go to Payroll App > Configuration > Salary > Structures
Select checkbox for any entry
Now click on the Action Button

**Issue:**
"Duplicate" action menu is displayed 2 times
![2024-04-29_14-40](https://github.com/odoo/enterprise/assets/145324067/ed4e7a77-b0aa-454b-a7e8-05dfbdd3923e)

**Cause:**
Prior to this update, the 'list_controller.js' file in version saas~16.4 did not included the "Duplicate" menu action within the [getActionMenuItems](https://github.com/odoo/odoo/blob/saas-16.4/addons/web/static/src/views/list/list_controller.js#L287-L325) function.
However, in the same version, the 'hr.payroll' model defined this action in the [hr_payroll_structure_views.xml](https://github.com/odoo/enterprise/blob/saas-16.4/hr_payroll/views/hr_payroll_structure_views.xml#L132-L143) file, utilized within the 'Salary Structures' in the Payroll app.

In version 17.0, the "Duplicate" menu action was added to the [getStaticActionMenuItems](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/list/list_controller.js/#L304-L349) function of 'list_controller.js'. Following the update, despite the addition of the "Duplicate" menu action in the 'list_controller.js' file for version 17.0, it still remained present in the [hr_payroll_structure_views.xml](https://github.com/odoo/enterprise/blob/17.0/hr_payroll/views/hr_payroll_structure_views.xml#L134-L145) file. 

**Fix:**
Removed the 'ir_actions_server_duplicate_structure' from hr_payroll_structure_views.xml, to ensure the same menu action "Duplicate" do not exist twice, in the 'Salary Structures'.

Affected Version: 17.0 ~ master

Task ID: [3854557](https://www.odoo.com/web#id=3854557&cids=2&menu_id=4720&action=4043&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#61666

[FIX] account_reports: hide lines at 0 when unfold

Problem: There are two way to see the issue :-
                       1- Whenever you go to the balance sheet and check on the hide at 0 option Then you go and
                            unfold-fold-unfold a line with one zero child and non zero child.
                            The line will with zero will keep showing up.
                      2- Mentioned in the task-3898147

Issue: when we check the option 'hide at 0' then we fold and unfold.
           The flow of func 'unfold Loaded Line' (the already loaded lines) has no clue about the 'hide at 0' option
           but on the other hand the func 'unfoldNewLine' (the new added lines) know about the 'hide at 0' option

Solution: Send the lines that we want to unfold to the 'assignLinesVisibility' logic that handle 'hide at 0'
                   as we do with 'unfoldNewLine'
Minor renames: setLineVisibility >> hideZeroLines, assignLinesVisibility >> setLineVisibility

Task-3898147

Forward-Port-Of: odoo/enterprise#61831

**Current behavior:**
When downloading sign documents via buttons in the form and tree views, user will get an access error on the read perm for the `sign.request.item.value` model.

**Expected behavior:**
These buttons should permit the download of the corresponding document.

**Steps to reproduce:**
1. In the Sign app go to Documents

2. In the tree view click the download button by a document which has not already been generated (e.g., any of the demo data documents)

**Cause of the issue:**
The download buttons call `get_completed_document()` which, if the completed doc has not been generated, will directly call `_generate_completed_document()` where we do a `read_group()` on the `sign.request.item.value` model. This model must be read with `.sudo()` because access rights are never granted to any group.

**Fix:**
Get rid of the `_generate_completed_document()` call in `get_completed_document()`, letting the program go to the `act_url` flow, into `download_document()`. Here we will access the `sign.request` record with `env.su is True` which will permit the `read_group()` later on in the aforementioned flow. Because we always route from `get_completed_document()` with a `download_type='completed'`, there is no reason to generate the document here.

opw-3834177

Forward-Port-Of: odoo/enterprise#61332
Forward-Port-Of: odoo/enterprise#60399