Currently, the Rules page lets you filter by product+channel with a dropdown. This is generally how we want to view the Rules, but it can also be useful to further pare down the Rules, especially for channels that have many of them. There's two use cases I have in mind here: 1) Simply shrinking down the number of Rules shown when working on a specific thing. 2) Using Rule filtering as a way to simulate how the Rules would evaluate for an update request with certain parameters. Eg: Will a request with version X, build target Y, and OS Version Z match in the way that I am expecting? The latter use case means that all of the matching done in the backend (https://github.com/mozilla/balrog/blob/2fb35857b6aa63723af07e966ba2b42dd7437de5/auslib/db.py#L1587) would need to be replicated in the frontend. I'm envisioning something like the column filter shown on http://legacy.datatables.net/release-datatables/examples/api/multi_filter.html, but because we don't use a table layout, it wouldn't quite look like that. The key part is being able to specifically filter multiple, individual parts of the Rule.

Nick and I were talking about this a bit yesterday. This might be best in a different bug, but another thing that would help is to be able to archive off old rules (eg, by setting a flag on the row). If we were able to do this for all Rules before the most recent watershed, the "working set" (the rules we actually need to modify) would show up right near the start of the rules. UI-wise, we'd probably want some indicator that older rules exist, and a way to show them all in detail. We could do various things: collapse each one into its header, collapse them all into one single header, add a checkbox for show/hide (like we have for scheduled changes). I'm partial to one of the first two options.