## Pull Request HOOT (PRHOOT) - part 18

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328

Enterprise: https://github.com/odoo/enterprise/pull/65657

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

Forward-Port-Of: odoo/odoo#171004

In commit [1], the "Themes Options" have been reorganized to make them
easier to find. With this relayout, the buttons style options have also
been modified in order to have a third choice "Flat", in addition to
"Fill" and "Outline". However, the way it was done causes some issues.

Indeed, it wrongly sets the `btn-(primary|secondary)-(outline|flat)` CSS
variables to `'True'` instead of the `true` boolean, and to `null`
instead of `false`, which is not correct. This happens because
`customizeButtonStyle` now sends boolean values to the `_makeSCSSCusto`
function, instead of strings representing these booleans. This results
in the backend RPC call setting the variables to the Python boolean
`True`, or to `null` in the falsy case because of the `"null"` default
value.

While it does not seem to break anything in general, there are issues
when using themes that redefine these variables (e.g. "Avantgarde",
"Enark", "Cobalt",...). Indeed, it is impossible to set the buttons
corresponding style to "Fill". This happens because choosing "Fill" is
supposed to set both variables to `false`, but because of the boolean
values being sent to `_makeSCSSCusto`, the value that is in fact set is
`"null"`. This therefore makes them fallback to the value defined in the
theme, forcing them to `true` and preventing the "Fill" style from being
applied.

This commit fixes these issues by properly giving string values to
`_makeSCSSCusto`. For already existing databases, all the variables that
have been set to `'True'` will have their value replaced by `true`,
thanks to the `o-map-omit` SCSS function. Note that the `'False'` case
is also added, in order to be consistent.

[1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086

opw-3957157

Forward-Port-Of: odoo/odoo#170015

Currently when applying a coupon for 10% on the order on the current order, the points awarded are 100% of the points instead of 90%. The loyalty program rewarding x points per $ spent.

The same behavior is also observed in the sale worflow.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Open shop session
* Select a customer
* Add a product (ex. Office chair 70$)
* Select **Enter Code**
* Enter the code `10pc`
> Observation: The order will grant 700 points instead of 630. The amount paid is 63$ with the code for 10% on the order.

Settings of the **Discount & Loyalties**:
* **Code for 10% on orders**
  * Rule: 
    * `Among` -> no restriction set 
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0
  * Reward:
    * `Discount`: 10% `on` order
* **Loyalty Program**
  * `Use points on`: Current & Future orders
  * Rule:
    * `Among` -> no restriction set
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0 
    * `Grant` 10 loyalty poins per $ spent

Idea of the fix
---------------
As discussed with DALA, discount should count toward points awarded. Here is how it should apply:
* If program_rule has no domain, all lines should count (except ewallet & gift cards)
* If program_rule has a domain, we should use all the lines where the product matches the domain (except ewallet & gift cards)

This applies for the computation of points based on the money spent.

Why the fix:
------------
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L917

Sale-wise, we replace `rule_products` with `so_products_per_rule.get(rule, [])`. We also replace `order_lines` by `lines_per_rule`.
* `rule_products` don't include discounts as they are computed on `order_lines` (all lines that are not reward lines). https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L834-L841 https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L889
* `so_products_per_rule` will include the discounts if they match with the program's domain.
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L844
* We don't need to exclude the free product reward lines from `lines_for_points` as the price is 0 on the SO. Shipping lines and free shipping rewards are not counted.

In pos, the fix is a bit different.

https://github.com/odoo/odoo/blob/4b9dee8fbe9aefde798c8543fef89c661cc85c57/addons/pos_loyalty/static/src/js/Loyalty.js#L908-L914

We first notice that this piece of code is never triggered as the structure of `program.id` is a number and `reward.program_id` is the following thus the last if statement is never true. A `.id` is added.
```
Proxy(Object) {id: 1, name: 'Code for 10% on orders', trigger: 'with_code', applies_on: 'current', program_type: 'promo_code', …}
```

This now means that we only count reward lines if they are from the same program. 

With the following if statement, it means that only the lines that are not reward lines are counted (which excludes discounts).

https://github.com/odoo/odoo/blob/eadfa4ee290a8b62956097aa66989eacff230275/addons/pos_loyalty/static/src/js/Loyalty.js#L921-L924

We conclude that those two ifs must be changed as we want a similar behavior as the workflow in sales.

We remove `orderedProductPaid` out of the if statement since it can be impacted by reward lines. We change the first if to excludes the reward lines only from the current program or from ewallet and giftcards. With this, `orderedProductPaid` now counts the discount lines from other program. (Similar to sales, where `amount_paid` is computed with `lines_per_rule`)

`totalProductQty` still applies only on non reward lines. (Same as sales)

opw-3858286

Forward-Port-Of: odoo/odoo#170563
Forward-Port-Of: odoo/odoo#164723

- In the Inventory app, go to Lots/Serial Numbers;
- Open any record;
- Click on the Traceability stat button;
- reload the page;

Before this commit, the message "No operation made on this lot." was
shown, even if there are operations. This occurs because the
TraceabilityReport lost the current model at reload (active_model).

Since [1] a new prop (a function called updateResId) was give to the
controllers components of the window actions to update the resId on the
action state and url, when needed. For instance, the form view after
saving a new record, will update the state and the url with the newly
created id.

Since [2], the prop was also given to the controllers components of the
client actions to update the resId.

There is a need to update more than the resId. This PR will introduce a
new prop with the aim to update the action state (updateActionState).
This props will allow the controller components to update the state and
push the new state to the router (updating the url).

In practical, this allows to push a new state in the url, keeping the
action service in sync. This synchronization between the router and the
action service allows the browser back/forward/reload to work as
expected.

Now, the TraceabilityReport can update the state, to add the
active_model to the url (as a query param), and be able to restore the
full state at reload.

[1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
[2]: https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe

Forward-Port-Of: odoo/odoo#170502

When the customer opens the product from Physical Inventory and tries to reload the page,
a traceback will appear.

Steps to reproduce the error:
- Go to Inventory > Operations > Physical Inventory
- Open any product > reload the page

Traceback:
```
KeyError: 'views'
  File "odoo/http.py", line 2254, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1829, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1849, 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 1827, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1834, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2059, 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 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/action.py", line 90, in load_breadcrumbs
    name = act['display_name'] if any(view[1] != 'form' and view[1] != 'search' for view in act['views']) else None
```

https://github.com/odoo/odoo/blob/a0af91d2a7fbf22b610240497a791fa6cb63cc25/addons/stock/models/stock_quant.py#L390-L398
Here, 'views' key is missing in the action.
When the user refreshes the page, 'load_breadcrumbs' method will be called here.
https://github.com/odoo/odoo/blob/afb35b9ea5392eb097e4fc7689cb98a64396aef9/addons/web/controllers/action.py#L90

In the action, 'views' key is not present.
so it will give the above traceback.

Earlier, if the 'views' key was not present in the action, It worked fine.
because 'view_id' was enough for the action.
since 'load_breadcrumbs' method, if 'views' key is not present in the action,
It will give the above traceback.

sentry-5132471164

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

Forward-Port-Of: odoo/odoo#167969

- Open the Employees app;
- Open the record of an employee, that have the onbording plan link in
    the chatter (for instance Abigail Peterson in runbot);
- Click on the onbording plan;
- Close the onbording plan dialog;
- Click on the Employees link in the breadcrumb to came back to the
    employees multi-record view;

Before this commit, a traceback was raised : `Invalid controller to
restore`. This issue occurs because when we load from a link/URL
(loadState), the controllers list is updated from the actions found in
the URL, this is done to be able to recreate the controllers (the
breadcrumb) from the URL.
This behavior is correct when the action has a target other than “new”
(i.e., when it's not a dialog). In the case of a target "new" (a dialog)
the controllers shouldn't be modified, to be able to interact with the
breadcrumb when the dialog is closed.

Now, only when the action has a target different from "new", the
controllers are updated from the URL.

Forward-Port-Of: odoo/odoo#170508

When you access the journal items list view with a `search_default_account_id` and try to modify the account on a line that has an analytic distribution, a validation error occurs.

### Steps to Reproduce

1. Install `account_accountant`.
2. Create an invoice with a line that has an analytic account and an account A.
3. Open the trial balance and access the journal items of account A using the three-dots menu.
4. Select the line from the invoice you created.
5. Attempt to change its account.

You will encounter the following validation error:

```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Analytic Line (account.analytic.line)
Constraint: account_analytic_line_account_id_fkey
```

### Cause

When accessing the journal items from the Trial Balance report, the `search_default_account_id` context key is automatically applied to filter the accounts you selected. However, using `search_default_` with a relational field also creates a `default_` context key for that field. Here, `default_account_id` is added to the context.

When changing the account on a move line that has analytic accounts, the system deletes the existing related analytic items and creates new ones. Analytic items have an `account_id` field. Due to the `default_account_id` context key intended for the journal items, the same key is erroneously applied to the newly created analytic item, leading to a validation error because of a foreign key constraint.

### Fix

I was thinking about cleaning the context but after discussing with JOL, we decided to only get rid of the problematic default key.

opw-3958980

Forward-Port-Of: odoo/odoo#168329

## Pull Request HOOT (PRHOOT) - part 18

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328

Community: https://github.com/odoo/odoo/pull/171004

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

Forward-Port-Of: odoo/enterprise#65657

Impacted versions:

 - 17.0

Steps to reproduce:
 1. Install l10n_mx_edi module.
 2. Go to Company ESCUELA KEMPER URGATE.
 3. Go to Settings / Automatic Currency Rates.
 4. Run manually the currency rates.
 5. Go to Accounting / Customers / Invoices.
 6. Create a new invoice with the next values:
    - Customer: "INMOBILIARIA CVA"
    - Currency: USD - Product: Any but set the UNSPSC Category (any)
 7. Confirm the invoice.
 8. Click send and print.
 9. Check CFDI and click on Click send and print.
 10. Open the generated xml

Current behavior:
 - TipoCambio have many variations depending of product and currency value:

Example: June 17th: have:
| Product                   | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1        | 18.538484  |
| [FURN_0004] Letter Tray   | 1        | 18.538558  |
| [E-COM09] Large Desk      | 1        | 18.538498  |

Expected behavior:

 - TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)

Inspired in: [l10n_mx_extended](https://github.com/odoo/enterprise/blame/f030d17e07ae7b10fe95e054eb27ba35101cfc96/l10n_mx_edi_extended/models/account_move.py#L178)

Forward-Port-Of: odoo/enterprise#64838

Currently, an error occurs while editing the customer form view when the '281.50' contact tag is not available

Step to produce:

- Install the 'l10n_be_reports' module.
- Go to the list view of 'Contact Tags' and delete the '281.50' record.
- Open the customer form view and try to edit it.

Stack Trace :

```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7fb69b00be20>, 'l10n_be_reports.res_partner_tag_281_50')
  File "odoo/tools/cache.py", line 103, in lookup
    r = d[key]
  File "<decorator-gen-5>", line 2, in __getitem__
  File "odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "odoo/tools/lru.py", line 34, in __getitem__
    a = self.d[obj]
ValueError: External ID not found in the system: l10n_be_reports.res_partner_tag_281_50
  File "odoo/http.py", line 2250, in __call__
    response = request._serve_nodb()
  File "odoo/http.py", line 1759, in _serve_nodb
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2055, in dispatch
    result = endpoint(**self.request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/custom/default/saas_worker/controllers/main.py", line 2305, in smtp
    proxy.message_process(None, message)
  File "addons/mail/models/mail_thread.py", line 1369, in message_process
    routes = self.message_route(message, msg_dict, model, thread_id, custom_values)
  File "home/odoo/src/custom/trial/saas_trial/models/mail.py", line 369, in message_route
    return super(MailThread, self).message_route(message, message_dict, model=model, thread_id=thread_id,
  File "addons/mail/models/mail_thread.py", line 1093, in message_route
    self._routing_handle_bounce(message, message_dict)
  File "addons/mail/models/mail_thread.py", line 754, in _routing_handle_bounce
    rec_bounce_w_email._message_receive_bounce(bounced_email, bounced_partner)
  File "addons/mail/models/mail_thread_blacklist.py", line 104, in _message_receive_bounce
    record.message_bounce = record.message_bounce + 1
  File "odoo/fields.py", line 1376, in __set__
    records.write({self.name: write_value})
  File "home/odoo/src/enterprise/saas-17.2/l10n_be_reports/models/res_partner.py", line 26, in write
    tag_281_50 = self.env.ref('l10n_be_reports.res_partner_tag_281_50')
  File "odoo/api.py", line 584, in ref
    res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
  File "odoo/addons/base/models/ir_model.py", line 2185, in _xmlid_to_res_model_res_id
    return self._xmlid_lookup(xmlid)
  File "<decorator-gen-43>", line 2, in _xmlid_lookup
  File "odoo/tools/cache.py", line 110, in lookup
    value = d[key] = self.method(*args, **kwargs)
  File "odoo/addons/base/models/ir_model.py", line 2178, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
```

An error occurs when the system tries to retrieve an external ID of the contact
tag  '281.50'at [1],  but it is not available.

link [1]: https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/l10n_be_reports/models/res_partner.py#L26

To handle this issue, add 'raise_if_not_found=False' if the contact tag  '281.50' is
 not available.

sentry-5499490971

Forward-Port-Of: odoo/enterprise#64878

…nents

- In the Inventory app, go to Lots/Serial Numbers;
- Open any record;
- Click on the Traceability stat button;
- reload the page;

Before this commit, the message "No operation made on this lot." was
shown, even if there are operations. This occurs because the
TraceabilityReport lost the current model at reload (active_model).

Since [1] a new prop (a function called updateResId) was give to the
controllers components of the window actions to update the resId on the
action state and url, when needed. For instance, the form view after
saving a new record, will update the state and the url with the newly
created id.

Since [2], the prop was also given to the controllers components of the
client actions to update the resId.

There is a need to update more than the resId. This PR will introduce a
new prop with the aim to update the action state (updateActionState).
This props will allow the controller components to update the state and
push the new state to the router (updating the url).

In practical, this allows to push a new state in the url, keeping the
action service in sync. This synchronization between the router and the
action service allows the browser back/forward/reload to work as
expected.

Now, the TraceabilityReport can update the state, to add the
active_model to the url (as a query param), and be able to restore the
full state at reload.

[1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
[2]: https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe

Forward-Port-Of: odoo/enterprise#65284

An error occurs when the system tries to access single values from multiple records at [1].

Traceback On Sentry:

```
ValueError: too many values to unpack (expected 1)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: iot.device(1, 2, 3, 4, 5, 6, 7, 8)
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, 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 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, 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 756, 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 76, in web_save
    return self.with_context(bin_size=True).web_read(specification)
  File "addons/web/models/models.py", line 164, in web_read
    for vals in co_records.web_read(field_spec['fields'])
  File "addons/web/models/models.py", line 87, in web_read
    values_list: list[dict] = self.read(fields_to_read, load=None)
  File "odoo/models.py", line 3610, in read
    return self._read_format(fnames=fields, load=load)
  File "odoo/models.py", line 3821, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
  File "odoo/models.py", line 6608, 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 4934, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 100, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-17.2/quality_iot/models/iot.py", line 16, in _compute_qcp_test_type
    self.qcp_test_type = types.get(self.type, '')
  File "odoo/fields.py", line 1202, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

To handle this issue, Implement an iteration to iterate records.

sentry-5540606405

Forward-Port-Of: odoo/enterprise#65604

**Current behavior:**
A product that is tracked via serial will have all of its lots displayed in the Schedule gantt view instead of just the ones which are part of the order.

**Expected behavior:**
Only the lots corresponding to rented quants of a product will be displayed.

**Steps to reproduce:**
1. Enable `Rental Transfers` in settings

2. Create a rental order with 1 of the demo printer products (they are tracked via SN already) and confirm

3. Open the rental schedule view, see that for the new order, all of the printers in stock with a SN are displayed

**Cause of the issue:**
Previously, the commit 8c90c7493ec was merged to fix an issue where you could not group by serial numbers in the schedule view for orders that were created while the 'Rental Transfers' setting was enabled.

This introducted this bug by not actually specifying which `lot_id`s of a product were part of an order- so it selected ALL `lot_id`s of ANY product in a rental order.

**Fix:**
Add a join on `StockMove` so we can select `lot_id`s which are exclusively in `StockMoveLine`s that are linked to `StockMoves` which correspond to a rental order.

opw-3977685

Forward-Port-Of: odoo/enterprise#64662
Forward-Port-Of: odoo/enterprise#64118

**Steps to reproduce:**
- Install account_reports
- Go to "Accounting / Accounting / Journals / Journal Entries"
- Create a new entry:
  * Accounting Date: [a date from last month]
  * Journal Items: [2 lines using accounts that are not of type "asset_cash" or "liability_credit_card"]
- Post the entry
- Create a journal:
  * Type: Miscellaneous
  * Default Account: [one of the accounts used for the created entry]
- Go to "Accounting / Reporting / Statement Reports / Cash Flow Statement"

**Issue:**
The default account from the newly created misc journal appears in the report even if it is not a bank-type (or cash-type) account.

**Cause:**
Previously, only account moves from a bank or a cash journal were taken into account in the report.
The default account of these journals is forced to "asset_cash" type. However, a fix has been made to allow some account moves from miscellaneous journals, which can have any type of account as default account.

**Solution:**
Only allow default accounts having "asset_cash" or "liability_credit_card" as type.

opw-3867312

Forward-Port-Of: odoo/enterprise#63989

Issue -->

With a large number of `account.move.line` and `pos.order.line` records, methods `_get_tax_details`, `_get_gstr1_hsn_json` and `_set_details_pos_lines` do not perform well.

Solution -->

In `_get_tax_details` -->

Replace the journal items recordset with a set of ids to do deletions. Move the fetch to when it is actually needed.

In `_get_gstr_hsn_json` -->

Prefetch the l10n_in_code values on `uom.uom` records that are used in the for loop. This optimization prevents additional hits to the backend.

In `_set_details_pos_lines` -->

Fetch `product.product` records and all the `uom.uom` records before the for loop to prevent additional hits to the backend when trying to fetch `product_id.type`, `product_id.l10n_in_hsn_code` and `product_uom_id.l10n_in_code`

Benchmark -->

For about 110k journal items and 95k pos order lines, the current implementation takes about 2800 seconds to finish computation.

After the fix, the process takes about 300 seconds to finish.

opw-3895401

Forward-Port-Of: odoo/enterprise#65364
Forward-Port-Of: odoo/enterprise#62305