Currently, the error arises when downloading e-Faktur without a 'Tax Number'.

Steps to reproduce:

- Install a 'l10n_id_efaktur' module (with demo data).
- Navigate to Invoicing -> Customers -> Invoices and open any invoice with an empty 'Tax Number' field.
- Click on the action button to download e-Faktur.

Stack Trace :

```
TypeError: 'bool' object is not subscriptable
  File "odoo/tools/safe_eval.py", line 365, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(801,)", line 1, in <module>
  File "addons/l10n_id_efaktur/models/account_move.py", line 143, in download_efaktur
    self._generate_efaktur(',')
  File "addons/l10n_id_efaktur/models/account_move.py", line 338, in _generate_efaktur
    output_head = self._generate_efaktur_invoice(delimiter)
  File "addons/l10n_id_efaktur/models/account_move.py", line 178, in _generate_efaktur_invoice
    eTax['KD_JENIS_TRANSAKSI'] = move.l10n_id_tax_number[0:2] or 0
ValueError: <class 'TypeError'>: "'bool' object is not subscriptable" while evaluating
'action = records.download_efaktur()'
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, 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 1824, 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 222, 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 46, in run
    result = action.run()
  File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
    res = super().run()
  File "odoo/addons/base/models/ir_actions.py", line 938, in run
    res = runner(run_self, eval_context=eval_context)
  File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
    res = super(ServerAction, self)._run_action_code_multi(eval_context)
  File "odoo/addons/base/models/ir_actions.py", line 770, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self))  # nocopy allows to return 'action'
  File "odoo/tools/safe_eval.py", line 379, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

When downloading e-Faktur, There's an issue at [1], Where the system tries to access elements of 'l10n_id_tax_number', but 'Tax Number' is empty, So 'l10n_id_tax_number' is considered as a 'False'.

[1] : https://github.com/odoo/odoo/blob/9c4194ad3387c55d39ec7bbef1c6414893098c6e/addons/l10n_id_efaktur/models/account_move.py#L168-L170

This commit fixes the above issue by adding a condition to ensure that the system only accesses an 'l10n_id_tax_number' if it is available.

sentry-5001664034

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

Forward-Port-Of: odoo/odoo#162096
Forward-Port-Of: odoo/odoo#155196

Several fixes to the chart_template loading, found because to `l10n_ng` not being able properly accounts and taxes.
See related PR.

1. **[FIX] account: defer recursive check**
  This bug is generally hidden in normal localizations because the `get_account_account` function reads `account.account-xx.csv` soon enough to create all the needed accounts.
   In `l10n_ng` there is no `account.account-ng.csv`, as it relies on the generic_coa. The chart_template's  `get_account_tax` function reads `account.tax-ng.csv` before `get_ng_account_account` is called.
   The `defer` function should check the account_tax fields and postpone them until the creates are done, but it only checks the "first level" and doesn't check all the way down to `account_tax.repartition_line_ids.account_id`.
  By making `defer` recursive we are able to properly postpone the creation of taxes after the accounts are made.

2. **[FIX] account: deferred repartition_line_ids need Command.clear**
   When we load a chart template, we generally create records from scratch. Some relational fields may get deferred, since the record they point at may not yet be created. These fields are then not created with the record itself, they are deferred by the `defer` function and they get updated after all creates.
   In case the field is `account_tax.repartition_line_ids` though, if we don't provide repartition lines on a tax, `account_tax._compute_invoice_repartition_line_ids` creates two fake ones.
   When the deferred field is populated, all the new repartition lines are added for a total of at least four, two fake ones (base, tax) and at least two regular ones (base, tax).
   Since there can't be two base repartition lines, the validation `_validate_repartition_lines` raises a ValidationError.
   This behaviour can be avoided if before creating relational fields' sub-records, we clear the existing ones.
   It should cause no harm since we are anyway creating or updating the parent record, for example: `account.tax <-- account.tax.repartition.line`.

3. **[FIX] account, l10n_it_edi_withholding: Templates submodels values not evaluated**
   Files in the CSV templates that had submodels didn't get their values evaluated.
    
   Example:
   `account.tax-xx.csv -> repartition_line_ids/use_in_tax_closing` was not evaluated by `account/models/chart_template.py`'s `_parse_csv` function, resulting in taxes having a "False" value still resulting as True.
    
   This already affects l10n_eg.
   In the process, code has been a little de-obfuscated.
    
   *(This came out while testing `task-3724926`. Even if they're not in the scope of the task itself, we noticed that withholding taxes have `use_in_tax_closing` to `True` and putting them to False in the CSV had no effect)*

4. **[IMP] account: compute the template function only once**
   The templating function is executed 5 times per Chart template instead of once. It may not be all this relevant, but the fix is very basic.

Note: `isinstance` should always be `list | tuple` instead of `(list, tuple)`

related PR: https://github.com/odoo/odoo/pull/148370
task-3607459

Forward-Port-Of: odoo/odoo#157918

### Steps to reproduce:
- Install **E-commerce** app
- Go to **Website** > **Shop**, and open a product
- Click on **edit** on the upper right corner.
- Double click the product image to change it. A popup is shown.
- In the popup, click on Add URL and place this URL [1]
- Click **Save**. The image disappears!

### Investigation:
- The issue was introduced here [2]
- As URL now starts with `/web/image/` which will be later used here [3]
- The condition to enter this line is `url_object.path.startswith('/web/image')`
- `item[field]` is used which equals to `attachment[datas]`
- But actually `datas` is empty as the image upload fails because of **CORS**
- `add_url` is called [4] saving attachment without `datas` but with type URL

### Fix
- The commit solves the issue by fetching the remote data from the server if the url is a remote redirection, which still happens when the image data cannot be fetched by the client browser at upload time.

[1]: https://lowendbox.com/wp-content/uploads/2022/09/odoo_logo_1200.png
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a#diff-0897c80484208197b0aff67f2b06509e864c3976de1589e3cebad2788eef008fR49
[3]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/models/ir_qweb_fields.py#L473
[4]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/controllers/main.py#L268

opw-3746245

Forward-Port-Of: odoo/odoo#160085

Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user.

This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user.

Steps to reproduce the issue
============================
1. Create a new employee
2. Link that employee to a new user
3. Remove the user to the employee (unset Linked user field)
4. Log in as that new user
5. Go to timesheets app

Current Behavior
================
A traceback is occured because the rpc called returned an empty list instead of a list containing at least one object to get the billable target for the current user.

Expected Behavior
=================
The grid view of Timesheets app should be loaded as expected and the leaderboard should not be displayed since no data is found to get the billable target for that current user.

opw-3862635
opw-3866805
opw-3864353

Forward-Port-Of: odoo/enterprise#61046
Forward-Port-Of: odoo/enterprise#60949