10 Aug
2021
10 Aug
'21
11:32 a.m.
Branch: refs/heads/master
Home: https://github.com/tribe29/checkmk
Commit: f5c96bb16d18094e05323cd25e4bd367d39b6a38
https://github.com/tribe29/checkmk/commit/f5c96bb16d18094e05323cd25e4bd367d…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2021-08-10 (Tue, 10 Aug 2021)
Changed paths:
M checks/rstcli
Log Message:
-----------
Make pylint happy. Only dictionaries have [] assignment
Change-Id: I43625810e95b917b29c70e8a44b580a93f936309
Commit: 2d0f163d23ea932834d173308dffe74a45865eb4
https://github.com/tribe29/checkmk/commit/2d0f163d23ea932834d173308dffe74a4…
Author: Óscar Nájera <oscar.najera(a)tribe29.com>
Date: 2021-08-10 (Tue, 10 Aug 2021)
Changed paths:
M cmk/gui/dashboard.py
M cmk/gui/plugins/dashboard/utils.py
M cmk/gui/plugins/views/graphs.py
M cmk/gui/plugins/views/utils.py
M cmk/gui/plugins/visuals/filters.py
M cmk/gui/plugins/visuals/utils.py
M cmk/gui/utils/urls.py
M cmk/gui/valuespec.py
M cmk/gui/views.py
M cmk/gui/visuals.py
Log Message:
-----------
Rebuild active filters on page load
Pages recover context on initial page creation. Either from on disk
setup or active filters( exclusive or no merge ). Active filters are set
and then recovered by the filter menu valuespec. This valuespec requires
the request var "_active" to asses active filters, and to specially
recognize deleted filters(which remain in the url).
Due to our heavy use of manual link composition either contextful or
contextless, we need to also supply the "_active" flag on all those
links a new. This lead to a lot of bugs, because the difficulty of
tracking all those places systematically.
For this reason, instead of updating the links. On page creation, if
filters are found on the request vars, the "_active" flag added by
reconstruction and then the context extracted. This removes bugs faster
than updating the links, and isolates the places for refactoring.
To find the relation between the htmlvar and its filter. And inverse
function is supplied. Each htmlvar should be uniquely linked to a
filter. And given the way we create our filters, that is true. Except,
some bugs did snuck in.
- event_host & event_host_regex. It has been verifiable broken since
1.6.0. Thus shamelessly update htmlvar, because no user has complained.
- site & optsite. optsite allows for site="", and is only used
explicitly from filter menu. Internally, we only use site. Thus we
make an exception and never translate to optsite.
- host_metrics_hist & svc_metrics_hist. They are actually the same, and
the reason to have svc_metrics_hist is to still be able to use this
filter when host is single host. Maybe that is not big enough of a
reason. People actually want top hosts cutoff, not top services with
same metric of host cutoff. Filter is poorly known, and we could even
better delete svc_metrics_hist
- The reuse test checks that registered htmlvars don't try to change
their filter ident, instead of being only first time registrations.
Reason for this is inventory filters are generated dynamically on
load_modules & load_plugins, and indeed they are loaded more than
once, especially on test runs.
A bit controversially, is to partially revert:
1566ae70f6fb0d3b2ae619a5db9666cbe8cd4096
That is removing the option in makeuri to keep_vars. This means, that on
the link instead of the active filters flag being passed explicitly
passed, the next page will reconstruct it. The consequence is that all
filters on the last URL will be considered instead of only the active.
This is like the usual behavior (pre 2.1) of always having the merged
context, but it becomes annoying if currently, actively deleting filters
is a feature. I bet on that use case being sporadic against users
clicking on links and them being broken. This gives us time to think
about a better refactoring.
Change-Id: I44aa5d22fdc41b3399be5979dfc5ea2501e8ce2d
Compare: https://github.com/tribe29/checkmk/compare/d9102c172f90...2d0f163d23ea