I re-enabled host list icons, they have been missing for a while. The
downtime icon logic used to be inverted, this fixes it. Also showing
acknowledgements now even if object is in downtime.
This re-introduces expensive columns been disabled time ago and adds
even more to it. We are now showing last comment, last ack comment and
service problem count on hosts in list views.
It still costs performance, but seems that we can stand it. I'd like
to add more like this to the host view.
This is still experimental. We normalize a lot of columns, this allows
us to sort in a convenient way while having nice "showable" columns.
When used as filters (same goes for ordering) however, functions and
operations on table columns often hinder the db from using indexes.
The new filter implementation allows us to override query creating per
single column, that's what this first sample is trying to show. We still
need to fix alias handling, so unfortunately I have to deal with "real
columns" in the case construct.
Performance gain in large environments is impressive, more to come.
This is a performance evaluation right now, we might delegate such
logic to paginator later on. Cuts load time for lists and/or dashlets
with complicated filters by 50% - only for those with limit=0 of course.
I'd like to reintroduce those columns, showing last object comment
and so one. Those joins are costly, we can fetch host comments way
easier directly from host object once we are here. But I guess we
don't even need it.
Might have been a JS issue, but instead of messing with the URL just
POSTing is easier here - and works. Filters from the search box are
now added flawlessly to the filter tree.
Module configuration now takes place in module detail view and does no
longer pollute our config tabs. Modules are now able to provide a bunch
of own config tabs, we don't really care what they use them for.
There is no way in ZF to have an input[type=submit] with an unescaped
label ( = value). I temporarily replaced all iconSubmitForms with
inputs labelled with "X" - as all we used them for were delete
operations.
autosubmit class got cleared for no reason after enabling autosubmission.
Please note that the fact that their submission leads to a new form is
another issue.
fixes#6540
Stumbled across two issues here:
* It's currently not possible to fetch all (*) columns from a DataView
* Backends are not able to tell their names
Worked around the first issue by naming all columns and implemented a
quick & dirty solution for the second one.
Different changes have been applied:
* Allow integer unix timestamps as parameters for timestamp columns
* Remove alias-rewriting from Url class
* Remove all traces of raw_timestamp
* Use new filters
This takes care of timestamp columns, modifies queries in a way not
depending on db functions, filters are passed through to subqueries
for better performance.
There are too many view scripts fiddling with namespaces. There is
still the url helper, not sure why it's not going to be used. I may
roll this back one far day...
Show current title, a well-formated value and a label for each area in a
tooltip and add the ability to customize tooltip labels of InlinePies
refs #6117
Every monitoring controller needs $backend, so why declaring it over
and over again. Created "moduleInit" dummy function in our base action
controller to allow such implementations without polluting init().
It doesn't make much sense to sort history by "hostname" hardcoded to
service-only host columns. Default is now timestamp DESC, internally
this is mapped to raw_timestamp.
This was never thought to be used in frontends. Frontend code ALWAYS
needs to work with unix timestamps, raw timestamps are used internally
(e.g. between View and Query) to achieve better search and sort
performance.
I guess this needs some more investigation, desiredColumns are the
ones the user asked for ([alias => ]column), with column being once
again an alias in the "real" query. Alias resolution used to work
better long time ago, we should reflect on this.
This doesn't make it much better but allows to build a package
libicinga-vendor-php placing those files to /usr/share/php/IcingaVendor
or similar.
refs #4075
Drop external auth configuration from config.ini and move
implementation into a single backend provider named
'autologin'. This provider can strip realm names from
username with a custom regexp.
fixes#6081
Instead of having two separate functions to get the prefix
and the formatted time interval the new functions return
both the prefix and the time interval.
refs #5981
IDO version is cached in a session namespace. This fails where you
are using multiple IDO backends with different versions. We still have
no backend-specific base class where we could handle this, so for now
I continue to do so in the IdoQuery.
This patch creates one namespace per Host/dbname combination.
Even PHP code in HTML comments will be executed. As the filter object
sometimes failes, this can result in an invisible "breaking" exception.
refs #6031
We want to make use of new IDO features without breaking compatibility.
This is a quickfix as otherwise we would currently break everything
below 1.10. Code contains a few TODOs as this needs improvement.
When using list/services for show/services (services for a single host)
we us an ugly PREG-based hack fixing the base link target. This got
broken by the multiselect feature, now it's working again. We need a
better solution for this.
People used to configure something like "dot.png'> <img ..." as their
service image icon. Those hacks will no longer work as we correctly
escape everything. This fix hinders Icingaweb from even trying to load
them.
BaseQuery should no longer be abstract but be usable as is as soon as
we stripped ResultSet-specific tasks. As "Base" suggests something that
must be extended, the name no longer fits. So this is SimpleQuery right
now.
Because the `ListController' should only operate on data views,
data views should be a proxy to their underlying queries.
The methods `DataView::fromRequest()' and `DataView::sort()' are from now on deprecated
because they are relaced by `$backend->select()->from($viewName)' and `DataView::order()' respectively.
The monitoring module's ListController should only operate on data views instead of queries.
Thus the applyRestrictions() method now expects a data view instead of a query. Further since
filters are subject to change the applyRestrictions() method now does nothing.
The `hostsAction()' no longer uses `DataView::fromRequest()' but selects the data view from
a monitoring backend. `DataView::fromRequest()' orders the underlying query which must be reworked
in the current scenario.
This partially reverts fcf7f7d6. The original intention was to have
no library code reading config. Moving code snippets to another lib
doesn't solve this. We need quick & easy access to a monitoring
backend, on CLI, in other modules and so forth. Duplicating so much
code again and again is not an option.
I prefer the former way of doing things unless we find a better
solution.
Thomas Gelf
Matthias Jentsch
Marius Hein
Carlos Cesario
Gunnar Beutner
Michael Friedrich
Eric Lippmann
Johannes Meyer