Steps to reproduce:
- Drop a "Share" snippet anywhere on the page and save.
- Click on the email icon.
- Your default email client should open with, as a subject line, the
title of the page where spaces are replaced by +.
=> This should not be the case, spaces should show as spaces.

Since the sharer refactoring in [1], the title of a page used in share buttons of the `s_share` snippet is encoded as a `URLSearchParams()`, which encodes spaces as "+" characters (see the specs [2] of the built-in method). This works fine for most share buttons, but not for email clients, which do not properly parse the "+". Typically, that means that the subject line of the mailto link is something like "Home+%7CMy+Website", which renders as "Home+|+My+Website" in a mail client, instead of showing spaces.

This commit uses another way to encode the title parameter, so that it works for every share button. It also replaces a space that was encoded twice for Whatsapp.

[1]: https://github.com/odoo/odoo/commit/5297388cd2aa1f693b04538c846c7025e243b09d
[2]: https://url.spec.whatwg.org/#ref-for-urlsearchparams%E2%91%A4

task-3603556

This issue occurs when the customer creates an operation with a 0.0 expected duration fields. An error is then generated when the customer creates a manufacturing order and selects that operation due to expected duration fields is set zero.

step to reproduce -
- Install the `Manufacturing`
- Click on  `Configuration > Operations `
- Create New  Operations.
   - Select the Bill of Material (ex - [FURN_8621] Plastic Laminate)
   - Default Duration fields must be 0.0
- click on `Operations  > Manufacturing Orders`
- Create New Manufacturing Orders.
- Select the Product (select the product which you selects while creating operation ex. FURN_8621] Plastic Laminate)
- Click on the `Overview` button.

sentry traceback-
```
ZeroDivisionError: float division by zero
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, 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 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 462, in call_kw
    result = _call_kw_model(method, model, args, kwargs)
  File "odoo/api.py", line 435, in _call_kw_model
    result = method(recs, *args, **kwargs)
  File "addons/mrp/report/mrp_report_mo_overview.py", line 19, in get_report_values
    'data': self._get_report_data(production_id),
  File "addons/mrp/report/mrp_report_mo_overview.py", line 78, in _get_report_data
    operations = self._get_operations_data(production, level=1, current_index='')
  File "addons/mrp/report/mrp_report_mo_overview.py", line 268, in _get_operations_data
    real_cost = expected_cost / workorder.duration_expected * bom_duration_expected
```

https://github.com/odoo/odoo/blob/8adb65993e77150ac711d8e64d1768284bfb49fb/addons/mrp/report/mrp_report_mo_overview.py#L268

after this commit, the customer will be able to set 0.0 in expected duration. 


sentry-4657725988

When using account.root (through account.account().root_id or
account.move.line().account_root_id) in read_group, we can have
inconsistent results because of how account.root is defined.

account_root is a view with the id field computed out of account codes,
but there can be the same account for several companies, so we can have
several same ID for different rows => this is not expected by the ORM
who expects one record by ID => in result, we get for example the values
in the pivot table of journal items be multiplied by the number of
companies if we group by "Account Root".

With this changeset, we add a small optimisation in ORM so if a group by
is ordered by a many2one, if the order of the many2one is "id" we don't
add a left join for ordering.

note: without the change, the added tests failed:

- in account, with 1000 as balance, and 2 as number of root with id=90090

- in test_read_group with a query containing a left join to o2m table

opw-[2282699](https://www.odoo.com/web#id=2282699&view_type=form&model=project.task)
opw-[2289440](https://www.odoo.com/web#id=2289440&view_type=form&model=project.task)
opw-[3288390](https://www.odoo.com/web#id=3288390&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#143199
Forward-Port-Of: odoo/odoo#120595

Have an Invoice partner with type Individual
Create an invoice with said customer confirm.
ZATCA invoice has warning "invoiceTimeStamp_QRCODE_INVALID".
```
{"type":"WARNING",
"code":"invoiceTimeStamp_QRCODE_INVALID",
"category":"QRCODE_VALIDATION",
"message":"Time on QR Code does not match with Invoice Issue Time (KSA-25).
           If ZATCA's SDK was used to generate QR Code, kindly use the
           latest version of SDK",
"status":"WARNING"}
```

This occurs because when the Invoice partner is an Individual the validation requires an additional QR code enclosing invoice information that needs to match the xml content.

In this case the IssueTime of the invoice was not matching because the QR is manually formatted with a wrong 'Z' at the end, while its timezone is, correctly, Asia/Riyadh

opw-3586326

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#143379

Steps to reproduce:
- Install l10n_sa_edi
- Switch to a SA company
- Create a 15% INCLUDED tax
- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - Product: [any]
    - Quantity: 90
    - Price: 200.00
    - Taxes: [the 15% INCLUDED tax]
- Confirm the invoice and process it by ZATCA service

=> The invoice is accepted by ZATCA, but there is the following warning:
`BR-KSA-EN16931-11 : Invoice line net amount (BT-131) must equal (Invoiced quantity (BT-129) * (Item net price (BT-146) / item price base quantity (BT-149))) + Sum of invoice line charge amount (BT-141) - Sum of invoice line allowance amount (BT-136)`

Cause:
The net unit price (200 / 1.15) has more than 2 decimals but its value is rounded to the decimal accuracy of "Product Price" (2 digits by default) in the generated EDI document.
When multiplying its rounded value with the quantity, the result is not equal to the invoice line subtotal, which is triggering the warning.

Solution:
Remove the rounding for unit price amount as there is no restriction on its number of decimals.

Reference:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_unit_price_amount
- https://zatca.gov.sa/ar/E-Invoicing/SystemsDevelopers/Documents/20230519_ZATCA_Electronic_Invoice_XML_Implementation_Standard_%20vTrack.pdf

opw-3509940




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

Forward-Port-Of: odoo/odoo#143131

[IMP] hw_posbox_homepage: Change logger level

Add the possibility to dynamically change the logger level of Odoo and per IoT handler (drivers and interfaces).
This will be done through the "Handler List" page.

This will be useful to troubleshoot purposes. In particular when it happens on a specific handler.

The level set should persist on shutdown as saved in Odoo's configuration using the `--log-handler` parameter, see:
https://www.odoo.com/documentation/16.0/developer/reference/cli.html#cmdoption-odoo-bin-log-handler

Notes:
 - When changing Odoo's level, `werkzeug` logger will change to the same level automatically (except in `debug` on which `werkzeug` will be set to `info`)
 - `--log-level` Odoo config wasn't used as it has unintended side effects when dynamically switching to this level
 - `load_iot_handlers` was modified as otherwise the loggers `__name__`  could be wrong and inconsistent on which several logger for a handler exists. For example: `PrinterInterface.py` and `odoo.addons.hw_drivers.iot_handlers.interfaces.PrinterInterface`. In this situation `_logger` can be different from one used in the class. In addition, of that, the parent logger for the different loggers could be different (root and Odoo generally)

Preview:
![image](https://github.com/odoo/odoo/assets/60775325/ee44f97b-a89f-46e0-b23b-9c2637ac8d4c)


opw-3493585

Forward-Port-Of: odoo/odoo#137547
Forward-Port-Of: odoo/odoo#134174

__Current behavior before commit:__
When searching for an **Internal Reference** of a product variant on the website shop, the fuzzy search is likely to return a wrong result.

If the **Internal Reference** of a product template resembles the searched term, it will take it as a fuzzy term and will not even search for product variants internal references.

This is because the method `_basic_enumerate_words` only parses the fields of the model considered but not the "subfields", in this case the `product_variant_ids.default_code`.

__Description of the fix:__
Run `_search_exact` in any case and only then, if no result is found, run a fuzzy search.

__To reproduce on runbot 15.0:__
In the website shop, search *FURN_0096*. Although there is a variant of *Customizable Desk* that has this exact **Internal Reference**, the search will only return *Office Chair Black* because this product template has a **default_code** set (*FURN_0269*).

opw-3476643

Forward-Port-Of: odoo/odoo#133584