For compatibility reasons, Icinga DB Web also applies hooks provided
for the monitoring module, so existing modules do not need to implement
new hook interfaces. The code paths that consume these hooks are already
guarded by installation checks, so no hook is applied if the `monitoring`
module is not installed.
Previously, when the `monitoring` module was not enabled, Icinga DB Web
would search module directories manually to register its autoloader,
logging an error if the module could not be located. This produced
noise in setups where the `monitoring` module is simply not installed.
The autoloader registration now uses the module manager directly and
is skipped entirely if the `monitoring` module is not installed.
(cherry picked from commit 04e0428888)
When exporting JSON with a limit and a page > 1 set, a leading comma is added
before the first item because `$offset !== 0` evaluates to true, resulting in
invalid JSON.
Replace the offset‑based condition with a `$first` flag to track whether any
item has been written yet.
(cherry picked from commit b60448bc77)
Add explicit return types to `ipl-orm`-derived methods to prepare for strict
typing. These additions are safe, as they only annotate existing methods that
previously lacked return type declarations.
(cherry picked from commit f8d4f92566)
2cd1f96c Fixes that a condition, to keep redundancy groups in the result
(as they cannot be subjected to restrictions), lead to expensive and
irrelevant sub-queries in cases where redundancy groups were not
fetched. (e.g. usergroups)
6cb15efc Changes restriction application so that restrictions of
multiple roles are merged together instead of being processed
individually. This helps the ORM to generate less sub-queries and I
suspect performance will also be improved, even if just slightly.
fixes#1294
(cherry picked from commit 3b77b1c956)
This hook usually runs isolated and no-one else requires a connection.
Makes only a difference in case of reporting triggering this as part
of a scheduled report and prevents the database connection from being
left open unnecessarily and failing upon re-use.
(cherry picked from commit e56d8a68ca)
Still hacky, but at least the combined str_replace
should compensate the preg_replace :D
I stopped thinking about a proper fix, as between the
time the original quick fix was implemented and now,
nothing has fundamentally changed in ipl-orm.
fixes#1330
(cherry picked from commit ab5304d4b0)
Previously, only the second and other subsequent item was updated with redis
results. Not sure why this wasn't discovered until recently, as the issue
was already part of the initial fix meant for a very similar issue, affecting
*all* items. Hell, maybe because my initial analysis this time also led me
into the wrong direction, so when reviewing this, proper testing and result
verification is key!
fixes#1318
(cherry picked from commit f70f60bf66)
We were somewhat *compatible* with 2.9. Though, our packages
never allowed to install Icinga Web < 2.12 together with
Icinga DB Web >= 1.2. The latter requires PHP 8.2 as a minimum
and only Icinga Web 2.12 is compatible with it. It's now time
to hard require Icinga Web 2.12, althoug you might argue that
we should have done that already with v1.2…
If saving the Redis settings fails due to a write error, the desired
configuration file content is now displayed so that the user can deploy
it manually (Same behavior as with database configuration).
For that a catch block is introduced on the `NotWritableError` that is
added to `IniWriter::write()` in
https://github.com/Icinga/icingaweb2/pull/5404.
Refs https://github.com/Icinga/icingaweb2/pull/5404Resolves#1269
This PR improves the UX in the IcingaDB Web interface by:
- Enhancing the page opening behavior in column views for smoother
navigation.
- Adding a search bar to the tabs Host Services, Host History and
Service History
## Resolves
- #981
- #1288
Previously, command forms were responsible for this. But they
don't have any notion of fallback handling and are unable to
ensure proper re-submission of failed batches.
* Auth: Add method `assertColumnRestrictions`
* ObjectSuggestions: Do not suggest protected variables
`assertColumnRestrictions` does not allow to use them
anymore, hence we should not suggest them in searches
as well to not to let the user run into an error by
accepting a suggestion. Though, when fetching values
as well, we still have to obfuscate, otherwise protected
vars won't show up in details anymore.
* Introduce Icinga\Module\Icingadb\Common\Model
Must be used as base for all models, to ensure
column restrictions are asserted on filters.
* Utilize `Icinga\Module\Icingadb\Common\Model` where applicable
