When a user Creates/Open GST Return Period, the error comes like tuple indices must be integers or slices, not str.

Steps to produce:
- Install the `l10n_in_reports_gstr` module.
- Accounting > Reporting > India > GST Return Periods.
- Create a new record.
- Error will be produced.

Seems like this issue comes because of the new API of '_read_group' instead of the 'read_group' method. It returns the tuple and the code expects the dictionary.

Sentry-4262634781

Traceback:
```
KeyError: <NewId 0x7f8d4f91ba90>
  File "odoo/api.py", line 959, in get
    cache_value = field_cache[record._ids[0]]
CacheMiss: 'l10n_in.gst.return.period(<NewId 0x7f8d4f91ba90>,).expected_amount'
  File "odoo/fields.py", line 1158, in __get__
    value = env.cache.get(record, self)
  File "odoo/api.py", line 966, in get
    raise CacheMiss(record, field)
TypeError: tuple indices must be integers or slices, not str
  File "odoo/http.py", line 2114, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1699, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1726, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1921, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 716, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 30, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 461, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 448, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "odoo/models.py", line 6702, in onchange
    snapshot1 = Snapshot(record, nametree)
  File "odoo/models.py", line 6476, in __init__
    self.fetch(name)
  File "odoo/models.py", line 6486, in fetch
    self[name] = record[name]
  File "odoo/models.py", line 6122, in __getitem__
    return self._fields[key].__get__(self, type(self))
  File "odoo/fields.py", line 1209, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1387, in compute_value
    records._compute_field_value(self)
  File "addons/mail/models/mail_thread.py", line 396, in _compute_field_value
    return super()._compute_field_value(field)
  File "odoo/models.py", line 4486, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 99, in determine
    return needle(*args)
  File "home/odoo/src/enterprise/saas-16.3/l10n_in_reports_gstr/models/gst_return_period.py", line 220, in _compute_expected_amount
    if total_by_company['company_id'][0] in (record.company_ids or record.company_id).ids:
```

Forward-Port-Of: odoo/enterprise#42912

## Current behaviour
As a public user, when filtering in the shop for a rental product using the datepicker, we are met with a 403 error, because we don't have access to the Warehouse model.

## Expected behaviour
You shouldn't have access errors when filtering rental products based on the date range.

## Steps to reproduce
- Install `website_sale_stock_renting`
- Create a rental product, set it's quant on hand to 1, don't allow it to be sold when out of stock
- Go to the shop page, edit the website, customize > daterange picker
- Go to an incognito windows (don't log in, so you are a public user)
- Go to "/shop" and filter based on a daterange you get a 403.

## Reason for the problem
The problem is 2 fold:
- lack of read access on the warehouse model, because in `_filter_on_available_rental_products` we are getting the `qty_available`, which triggers `_compute_quantities/_compute_quantities_dict/_get_domain_locations ` which does a search on the Warehouse model. The public user doesn't have read access to this model. (The module doesn't define any access rules).
- lack of read access on the `sale.order.line` model, used in `_filter_on_available_rental_products` to check the availability of a variant.

## Fix
The module doesn't define any security rules, but instead of creating brand new access rights, that would grand read access to both `sale. order.line` and `warehouse` models to all public users, use a `sudo` at the problematic call site in the controller that is calling `_filter_on_available_rental_products`.

## Affected versions
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master
---
opw-3318852

Forward-Port-Of: odoo/enterprise#42791

Steps to reproduce:
- activate analytic acccounting
- in accounting report>schedule depreciation>options: activate analytic groupby
- create an asset: amount 10k, start date (01/01/23), analytic account "administrative"
- Open the Depreciation Schedule and set the analytic groupby with analytic account "groupby"

Issue:
The groupby does not exclude assets that do not have the analytic account set in the groupby option

Cause:
The analytic groupby has not been implemented for the `account_asset_report` (Depreciation Schedule Report))

Solution:
(1) Add to the `_query_values` the analytic information for the Asset Line.
(2) Modify the signature of the method `_query_lines` in order to have the `column_group_key` information
=> Now that we have `column_group_key` information, we can retrieve which column we are processing and find the dedicated forced options(*).
From those forced options, we get the `analytic accounts` and we compare it to the `asset_analytic_distribution` of the Asset Line that is availble thanks to (1).

(*) the analytic groupby options are set in the `forced options` in`_create_column_analytic`:
https://github.com/odoo/enterprise/blob/4cf8213f88f5eee45382386a3389e51cb2b75f4b/account_reports/models/account_analytic_report.py#L71-L77

opw-3344182

Forward-Port-Of: odoo/enterprise#42960
Forward-Port-Of: odoo/enterprise#42590

While creating a Journal Entries , if the value of 'tax_closing_end_date' field is passed as null. As 'tax_closing_end_date' field is not required, there might be a case where it can be null/False.

Traceback will be generated.
```
TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'
  File "odoo/http.py", line 2115, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1698, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1725, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1922, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 234, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 715, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 28, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 24, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 461, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 448, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "home/odoo/src/enterprise/saas-16.2/account_reports/models/mail_activity.py", line 13, in action_open_tax_report
    return move.action_open_tax_report()
  File "home/odoo/src/enterprise/saas-16.2/account_reports/models/account_move.py", line 75, in action_open_tax_report
    options = self._get_report_options_from_tax_closing_entry()[1]
  File "home/odoo/src/enterprise/saas-16.2/account_reports/models/account_move.py", line 142, in _get_report_options_from_tax_closing_entry
    date_from = date_utils.start_of(date_to + relativedelta(months=-delay), 'month')
```
This commit will resolve this issue.

sentry-4212662929

Forward-Port-Of: odoo/enterprise#42699
Forward-Port-Of: odoo/enterprise#41622