Description of the issue/feature this PR addresses:

Commit [1] fixed a bug where selecting across two paragraphs separated by
whitespace resulted in multiple indented lists. However, this fix introduced
a new issue: if a first child of block node was whitespace followed by a `<br>`,
the list was not created on the first attempt. Instead, only the whitespace was
removed, and the list was created on the second attempt.

Commit [2] addressed this issue but introduced a new problem: if a block node had
whitespace as its first child, the placeholder for that block would enter an
infinite loop, causing the page to become unresponsive.

This commit reverts the changes made in Commit [2] and introduces a new approach
that resolves the list creation issue when a block node had whitespace as its
first child, without causing the placeholder to get stuck in a loop.

[1]: https://github.com/odoo-dev/odoo-editor/commit/58a7fadcaaaa7322c6177276ddc22b62da96d1f5
[2]: https://github.com/odoo/odoo/commit/1e982dab025fb86e759b249433f41619a442b5cf

task-4082867

[FIX] website: avoid page template to crash at preview removed

Steps to reproduce:
- On the website, click on "New" then "Page" to create a new page.
- On the blank page, click on "Use this template".
- Insert a file name (e.g. `rte_translator.xml`) and click on 'Create'.

-> If the last operation was fast enough a traceback of type `TypeError:
Cannot read properties of null (reading 'fonts')` can occur.
Note that to be able to reproduce the problem, a delay may have to be
added in the `onceAllImagesLoaded` method and the operations of file
name insertion and page creation have to be quite quick (you can for
example use the `rte_translator` test tour).

Since [this commit], it is possible to create new pages from templates.
The problem here is that the template preview is removed before the
`onMounted()` operation of the `AddPageTemplatePreview` component
finished. Due to it, the content document of the preview iframe is not
set and trying to search for its `fonts` leads to an error. This commit
fixes this issue by ensuring that the component has not been destroyed
before continuing its `onMounted()`  process.

[this commit]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7

Steps
---
* install `stock`, `sale_management`
* configure reception in 2 steps
  (*Setting > Multi-step routes* + *Configure Warehouse Routes*)
* make *Stock/Input* a return location
  (*Inventory* > *Configuration* > *Stock/Input* form)
* create an SO for 5 units of a storable product (say P)
* (put at least 5 of P available in stock)
* confirm it > go to the delivery > validate
* *Return* > from the wizard set *Stock/Input* as the return location
* validate the `Customers -> Input` receipt
* validate the `Input -> Stock` internal transfer
* => on the orignal SO the delivered quantity is now -5 instead of 0

Cause
---
When generating moves in a push rules, we copy the fields of the
generating move, including `to_refund`, so both moves affect the
delivered quantity.
But when we check if a return move should affect the delivered/received
qty on SO/POs, we only check the `usage` of the destination location;
so in the case of multi-step routes, moves further down the chain
will affect the qty twice or more, and we will have a negative
delivered quantity

Fix
---
Use a stricter check to determined which moves should affect SO
quantities

opw-4129497

Before 020ddc3a we allowed any Python identifier as column names. The usual field definition `name = fields.FieldType(...)` restricts  `name` to be a valid Python identifier. Forbidding it in 17.0 causes issues during upgrades.

For example, with the model:
```py
class CustomModel(models.Model):
    _name = 'mymodule.custom.model'
    _description = "custom"

    année = fields.Char()
```

In 17.0 before this patch we get errors like:
```
  File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 150, in identifier
    assert IDENT_RE.match(name), f"{name!r} invalid for SQL.identifier()"
           ^^^^^^^^^^^^^^^^^^^^
AssertionError: 'année' invalid for SQL.identifier()
```





### Possible issue during upgrade from < `17.0` to >= `17.0`:

1. Install fresh db in `16.0`
2. Add custom field `année` to the `res.users` with custom module
3. Go to `Settings --> Manage Users` add the field `année` in the list view
    by installing studio
4. Upgrade to `17.0`

You will get error like this:

```
('base.menu_action_res_users', 64, 'Settings > Users & Companies > Users', 70):
 Traceback (most recent call last):
   File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 429, in mock_action
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 557, in mock_view_tree
    self.mock_web_search_read(model, view, [domain], fields_list)
   File "/tmp/tmpcmtylywh/migrations/base/tests/test_mock_crawl.py", line 591, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80)
   File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5756, in search_read
    records = self.search_fetch(domain or [], fields, offset=offset, limit=limit, order=order)
   File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1648, in search_fetch
    return self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 545, in _fetch_query
    records = super()._fetch_query(query, fields)
   File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3929, in _fetch_query
    sql = self._field_to_sql(self._table, field.name, query)
   File "/home/odoo/src/odoo/17.0/odoo/models.py", line 2863, in _field_to_sql
    return SQL.identifier(alias, fname)
   File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 153, in identifier
    assert IDENT_RE.match(subname), f"{subname!r} invalid for SQL.identifier()"
 AssertionError: 'année' invalid for SQL.identifier()

```


Actually, the issue can occur anywhere that the new `SQL.Identifier()` is used.

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

The PR https://github.com/odoo/enterprise/pull/68325 did remove the usage of `select_iot` in the view. However, as it was made on 17, client with already installed IoT app might have the previous version of the view (thus using `select_iot`).

These customers with out-dated view will have a traceback after clicking the "Print" button:
```py
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
  File "/media/loan/work-encrypt/Odoo/code/version/17.0/odoo/odoo/http.py", line 1783, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  ...
  File "/media/loan/work-encrypt/Odoo/code/version/17.0/odoo/odoo/api.py", line 461, in call_kw
    raise AttributeError(f"The method '{name}' does not exist on the model '{model._name}'")
AttributeError: The method 'select_iot' does not exist on the model 'select.printers.wizard'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
    RPC_ERROR
        at makeErrorFromResponse (http://127.0.0.1:8069/web/assets/debug/web.assets_web.js:27903:19) (/web/static/src/core/network/rpc_service.js:37)
        at XMLHttpRequest.<anonymous> (http://127.0.0.1:8069/web/assets/debug/web.assets_web.js:27951:27) (/web/static/src/core/network/rpc_service.js:85)
```

opw-4152608

Currently, the share panel cannot be closed once it has been opened. This commit resolves the issue by preventing the share panel from closing only when the active element is a modal.

Steps to reproduce the issue:
1. Open Knowledge.
2. Click on the share button to open the share panel.
3. Click on the share button again to close the share panel.
 
=> The share panel remains open.
TO BE: The share panel should close.

Details:

In the `KnowledgeTopbar` component, we added external event listeners to detect when the dropdown menu is opened, closed, or about to close.

When the dropdown is about to close (i.e., when the `hide.bs.dropdown` event is triggered), we check if the active element is the HTML document. If the focus is on another element, we prevent the dropdown from closing. This mechanism was added to prevent the dropdown from closing when users are adding new members through the invite modal.

Using the `useActiveElement` hook, the active element can change when a component is mounted. When the web editor in Knowledge is mounted, the active element becomes the editor toolbar. As a result, the active element is no longer the HTML document, and the event listener always prevents the dropdown from closing.

To resolve this issue, we will now check if the active element is a modal before preventing the dropdown from closing. This ensures that the dropdown behaves as expected and the share panel can be closed when necessary.

Reference: https://github.com/odoo/odoo/pull/175880

task-4179706

When the no-content helper is shown and the user clicks on the "New" button to create a new article, the sidebar lists the newly created article in the "workspace" and in the "private" section. This is an undesirable behavior as the newly created article should only appear in the "private" section.

When no record is passed to the form view, the form view creates a virtual record. When the user clicks on the "New" button, the system will create a new article and open it using the `openArticle` function defined in the component environment.

When calling the `openArticle` function, the function will check if the article has a title and, if it hasn't, it will fetch the first heading of the article and use it as title (see: `ensureArticleName`). If the record is not virtual, the function `openArticle` will then persist the changes made on the current record before opening the new record.

For its part, the sidebar listens to the changes made on the loaded record (using a record observer) and updates its state based on the record changes. When calling the `ensureArticleName`, the title of the virtual record changes and the sidebar detects that change and adds a new entry for the virtual record. The sidebar will then add another entry for the newly created record.

To fix the issue, the `openArticle` function will no longer call the `ensureArticleName` function when the current record is virtual. The virtual record state will hence no longer be updated when opening a new article. As a result, the sidebar will not detect any change and will no longer create an entry for the virtual record.

Note that there was actually no reason to update the title of the virtual record as it gets discarded when leaving Knowledge.

Steps to reproduce the issue:
1. Delete all articles from the database
2. Open the Knowledge editor (you should see the no-content helper)
3. Click on the "New" button

=> There is two entries for the new article: one in the "workspace" section and one in the "private" section.

TO BE: There should only be one entry in the "private" section.

task-4160386

When ```KE eTIMS: Fetch KRA notices from eTIMS``` cron runs and eTIMS API returns
an error, a traceback will appear.

Steps to reproduce the error:
- Install ```l10n_ke_edi_oscu```
- Set up Kenya eTIMS Integration
- Run ```KE eTIMS: Fetch KRA notices from eTIMS``` cron

Traceback:
```
KeyError: 'noticeList'
  File "odoo/tools/safe_eval.py", line 391, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(909,)", line 1, in <module>
  File "home/odoo/src/enterprise/saas-17.4/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py", line 35, in _cron_l10n_ke_oscu_get_notices
    notice_map = {notice['noticeNo']: notice for notice in data['noticeList']}
ValueError: <class 'KeyError'>: "noticeList" while evaluating
'model._cron_l10n_ke_oscu_get_notices()'
  File "odoo/addons/base/models/ir_cron.py", line 562, in _callback
    self.env['ir.actions.server'].browse(server_action_id).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 989, 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 821, 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 405, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

https://github.com/odoo/enterprise/blob/019a7cdd5a3071c0948656bdcacc95b63c2e8842/l10n_ke_edi_oscu/models/l10n_ke_edi_oscu_notice.py#L35 When eTIMS API returns an error, data will be empty,
So, it will lead to the above traceback.

sentry-5804573762, 5809459581

options['journals'] contains a list of dictionaries. In the typical case, they each will correspond to a selectable account.journal. Though, they can also contain journal groups, and in multicompany, some of them may serve as dividers between companies (for ease of rendering in the template). Those latter elements will then have 'divider' under their 'id' key, instead of a model id.

The Journal Report, when being opened for the first time unfolds the first available journal, by default, taking therefore the first element from options['journals'], generating a report line id from it, and adding this id under the 'unfolded_lines' of the options in its _custom_options_initializer. The thing is, doing so, no check was done that the id being used was indeed an account.journal's. A journal group id or 'divider' could also be used.

When 'divider' was added, the report crashed as soon as the options were used as previous_options in a subsequent call to get_options, since it tried to parse it as an integer.

We fix that by properly filtering the available journal ids to only contain actual account.journal ids.