Fixes#104
@status filter was added to the master branch to support new status key from Alertmanager >=0.6.1
status ended up being nested in Alertmanager (it was added to solve AM issue 609 and that was a long PR with lots of changes), current unsee implementation ended being slightly off with how Alertmanager is naming this, it should actually be @state rather than @status.
Expose counts of all alert statuses in each group (active, suppressed, unprocessed) instead of only active, and if a group contains only unprocessed alerts then color it as gray
When silence form is ready we should generate initial JSON preview, so when user clicks to show it there's something to show. Right now it's only generated if user changes something.
We have a static list of matchers, one for each kind, but newMatcher() was writing to those on every filter creation. Remove writes, set the attribute on matcher init instead.
Alertmanager 0.6.1 can return multiple instances of the same alert either in a different block object or as a duplicated alert group, ensure that we deduplicate those
@silenced=true should now be marked as invalid filter, but it isn't, this commit refactors it so that instead of looping over all filters and falling back to fuzzy (which is very relaxed checking and can't find typos in filter names like @statuz=active) we tokenize the expression into '<filter name> <operator> <value>' and only fallback to fuzzy if there's only a static text (no filter name and operator). This is more manual but provides stronger checks so now @silenced=true is correctly marked as invalid
Now that Alertmanager provides status=(unprocessed|suppressed|active) in the API it doesn't make sense to keep having separate filters for each value, merge @silenced & @inhibited into a single filter, update docs and UI
If user clicks on a silence button we make AJAX call to the /alerts.json endpoint to get all instances of given alert so we can allow user to select from all labels used. But it's possible that this alert will be resolved by the time user clicks on it, when this happens we simply list no labels, which might be confusing, show a message so user knows what happened.
This will allow moving away from manually captured/edited mock API responses and start generating them by sending alerts & silences to a live Alertmanager instance
