Previously custom variables that didn't match any of the desired
sources were eating up the query's limit and so there is a chance
that not even a single variable was listed. This especially
occurs with the updated notifications integration, as the available
database columns are very limited in number. But even in other views
this may have been noticed by users in case they have many variables
that are similarly named but have no overlap with database columns.
(i.e. input that doesn't match any database columns but many vars)
This introduces a new model `TacticalStateSummary` that represents a
union of `HoststateSummary` and `ServicestateSummary`. The union of both
is required to have the default export functionality also yield results
for both types of states as it only evaluates the first query. Now,
CSV/JSON exports also contain service states. Both can be differentiated
either by looking at the column data types (`null` for `hosts_*` columns
means it's a service state summary) or by simply checking the `type`
column which is either `'host_state'` or `'service_state'`.
fixes#1334
This ensures that exports to CSV/JSON contain results
for both host and service states as the default export
procedure only evaluates a single query.
fixes#1334
This PR adds a new `V2/Icinga2Source` hook implementation to integrate
with the `V2/SourceHook` interface from `icinga-notifications-web`.
### Supporting changes required by the hook:
- Introduce `QueryValuesProvider` — Decouples value suggestion logic
from `ObjectSuggestions` into a standalone Generator-based class. This
allows the hook's `getValueSuggestions()` to reuse the same suggestion
infrastructure without a `Suggestions` context.
- `QueryColumnsProvider`: Add `setShowRelationLabels()` setter — Exposes
the relation label display option so the hook can control it.
- `QueryColumnsProvider`: Make `collectFilterColumns()` protected — No
longer needs to be public; the override in `SearchControls` that called
it statically is removed as the optimization it provided is no longer
necessary.
- `ObjectSuggestions`: Remove label-to-path resolution for columns with
spaces to ensure consistency between the suggestions in the search bar
and suggestions provided by the `Icinga2Source`.
resolves: #1365
### Requires:
- https://github.com/Icinga/icinga-notifications-web/pull/469
- https://github.com/Icinga/icingadb-web/pull/1375
- https://github.com/Icinga/ipl-orm/pull/161
The code has been moved directly to the `QueryValuesProvider` class.
`QueryValuesProvider`: Bypassing the ORM is no longer required.
necessary and has been removed. The yield type must be an array
containing at least the keys `search` and `label` for `searchSuggestion`
to work. Previously these keys were created by wrapper classes.
Remove the overwritten method `fetchFilterColumns` of `SearchControls`
trait as this optimization is no longer necessary. Since the method is
now only used within its own class, it can be made protected.
Moving the code to `QueryValuesProvider` does not seem helpful, as
this covers a rare case that is not really necessary.
To ensure consistency between the suggestions in the search bar and in
`SourceHook`, this must be removed.
Decouple value suggestion logic into a standalone `Generator` instance.
This allows callers to fetch column values without any `Suggestions`
context. A plain `foreach` on the provider is enough.
`ObjectSuggestions::fetchValueSuggestions` is reduced to a thin wrapper
that resolves label-to-path input before delegating to the new class.
Previously `Url::setParams()` was used by `ServiceController::historyAction` to set `name` and `host.name`,
since the function overwrites all parameters the sort parameter was not included in the loadMoreUrl.
`UrlParams::addValues` fixes this problem sicne is keeps the existing parameters.
For consistency `HostController::historyAction` is also adjusted to match this implementation.
Two issues were fixed in the split regex:
1. Special characters before `.` were ignored:
The old regex only split on `.` when directly preceded by a word
character (\w), causing splits to be missed when `.` was preceded
by special characters like whitespace, / or $.
Result before: `foo /.bar.one` => `['foo /.bar', 'one']`
Result after: `foo /.bar.one` => `['foo /', 'bar', 'one']`
2. Brackets mid-word were incorrectly split:
The old regex split before any `[`, causing keys like `con[0]cat` to be
split incorrectly.
Resulti before: `con[0]cat` => `['con', '[0]cat']`
Now splits before `[` only when it's a standalone array index — meaning
`]` is followed by `.`, another `[`, or end of string.
Result after: `con[0]cat` => `['con', '[0]', 'cat']`
- Keep bracketed state labels as text inside plugin output (state-ball
replacements)
- Hide the text visually while preserving the existing state-ball
styling
Nice when copy&pasting plugin output to a code agent.
---------
Co-authored-by: Fabian Salomon <4098510+fsalomon@users.noreply.github.com>
`timestamp-toggle.js` listens to changes of `timestamp-toggle-control`
and clicks on `.toggleable-timestamp` elements and toggles their
`hidden` attribute.
It also updates the `timestamps` parameter in all relevant URLs.
Add a `useRelativeTimestamps` flag to `EventRenderer` and `NotificationRenderer`.
For timestamps that support switching between relative and absolute time
two `time` elements are rendered, with only one visible, so the frontend can
easily switch between them.
Rename and specialize the list for history views.
Insert a day-separator between entries of different days,
to support this when load-more is used the a URL parameter
with the date of the most recently added element is added to the `loadmoreUrl`.
The css for these new classes is added and `action-list.js` is adjusted so it
skips over the day-separator.
Introduce `createTimestampControl()` which returns a `TimestampToggle`.
The current mode is resolved from the URL param, the user's session
or the stored preferences and is saved on submit of the toggle.
The saving of view-modes is adjusted so it does not overwrite
the new `icingadb.timestamps` key in the preferences.
