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.