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
This makes unsee work with 0.6.1, but the new status means that we should refactor unsee data model and pull inhibited and silenced into it, with a single filter
Event listeners are setup on the modal div, but that div is not removed when the modal is hidden, only its children. This means that event listeners are stacked every time you show and hide a form. To reproduce this issue:
1. open silence form, click up button above hours, it will increment from 1 to 2
2. hide the form
3. re-open silence form, click up button above hours, it will increment from 1 to 3
4. repeat and every time increment will get a new listener that will cause higher value bump
This PR moves all listeners to the silence form element, which is removed when modal is closed, so all even listeners are destroyed properly and this bug no longer gets triggered.
Same fix is applied to the quick filter modal, it's present there but the effect there isn't as visible
There's a bogus duplicated mouse event for a.silence-duration-btn, which I added to fix css issues, get rid of it and replace with proper css selectors. And with that drop the event.stopPropagation call as it shouldn't be needed anymore
This moves raven init into a dedicated file where it's configured on load, we no longer load it on /help, but there's only css there so there wasn't anything that could fail anyway. We will also now fail in the most visible way if the value passed to raven is invalid (as in invalid syntax)
