feature request: hide silenced/occurrences settings as url param.
currently it seems setting hide silenced checks, silenced clients and below current threshold are all stored as cookies. This makes it hard to give someone a url with the current view you are currently looking at. I suggest they'd be more useful in the url. (like search)
It's also annoying for dashboards on wall monitors. We have them remote managed in several offices and it's troublesome to make sure that that someone has selected the right options on all of them to get the cookies set. ( we generally hide silenced. )
+1 to this feature
+1
+1
:+1:
+1
+1
+1
Let's store all filters in the URL so you can pass it on.
Interesting. I was looking for the opposite of this, but I would be in favour of having those features work hand in hand, properly.
We usually navigate around and as you can "tab open" an event's details you will click at links like the event list again. Stuff that is stored in cookies (like the hidden filters) will reactivate properly, whereas stuff like searches get lost. For those you need to navigate back.
Not sure whether I should open a more general ticket for this. Looking at the code it seems that it shouldn't be too hard to adapt this, but I might be missing something.
Aha! And I noticed this might be even more interesting. So client/event pages do have deep links, but you have to click on the table first to get to them. This is annoying in combination with loosing your filters (without going back). OTOH if you pass someone a URL with filters you don't want to screw up their session/cookie-based configuration. Interesting.
I think the best solution is to just store all of the filters in the URL all of the time. If someone passes you a URL and you click it, you can always go back to restore your previous filters. People will also edit the URL directly when there's something they don't want in it.
The more stateless the app is, the fewer surprises you encounter. Search queries are usually always in the GET URL params in any application.
Then we should probably consider dragging those parameters around while navigation, to avoid dropping people off of their "painfully" configured search all the time.
+1 please