Currently, a traceback is occurring when the user tries to compare `periodically` 
in account reports having a `fiscal year` of date today.

To reproduce this issue:

1) Install Accounting
2) Enable fiscal year from accounting settings
3) Now create a fiscal year record with `start` and `end` dates as today 
4) Open balance sheet report
5) Filter the comparison as `Previous Period`

Error:- 
```
TypeError: can't compare datetime.datetime to datetime.date
```

After the recent changes from this commit https://github.com/odoo/enterprise/pull/48530/commits/4f0432e86de6d6f4e8f78f11dbba1f8f2b4dafe5, this error is occurring. 
Because `period_date_from` is getting from `fiscal_year`, which is a `datetime.date` format.

https://github.com/odoo/enterprise/blob/4c1947963be235f733a56ee3d04b9f8f64d213ea/account_reports/models/account_report.py#L4769-L4775

But here the `comparision_date_from` is of type `datetime.datetime`, 
which leads to a traceback when comparison is done between both.

https://github.com/odoo/enterprise/blob/4c1947963be235f733a56ee3d04b9f8f64d213ea/account_reports/models/account_report.py#L4796-L4797

When the fiscal year record is there we can convert it to datetime.datetime, 
By doing this we can resolve this issue.

sentry-5695535237

Forward-Port-Of: odoo/enterprise#69721

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

Forward-Port-Of: odoo/enterprise#69727

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

Forward-Port-Of: odoo/enterprise#69861