Feature Request
Temporary filters should support the same features (message, user agent, wildcards) as inbound filtering
nathanielcook
There are a few discrepancies between the new inbound exception filtering and the temporary filtering available at the top of the main application screen (via the Add Filter button). The newer inbound exception filtering is more powerful in that it supports wildcards, while the temporary filtering available at the top of the main application screen does not. What's more, one can temporarily filter by version, tag, browser, operating system, host, machine name, assigned user, and assigned team, but not by user agent or message. It seems to me that every way one can filter inbound exceptions should also be available when filtering temporarily.
Raygun
John-Daniel Trask
Posted on
Sep 09 2016
Hi,
Yep, there are, because inbound filters are completely different :-) When processing an error we can review any property really easily and discard any matches. Pretty simple stuff really.
Filtering is doing a search across all instances (for some customers this is hundreds of millions of crash reports), all at once. We do add new filters from time to time, but they do require changes to the underlying data store to ensure they run effectively. It takes longer to build, manage and increases costs.
You can do:
- User agent filters (choose browser). This has the benefit that we roll up the user agents of known browsers to make it more manageable (e.g. filter on 'Chrome'), but anything that's unknown, you can still filter on.
- Messages can be done with the search (the search is pretty powerful, so you can lock it to the message field - though we should add this as a filter also to make it a bit easier to work with rather than relying on the syntax supported by the search field. Will chat to the team about that).
- Wildcards can be supported by some fields, we can investigate that.
But generally speaking, these are significantly different features that just happen to look somewhat similar. If we aim to maintain parity, we won't be shipping new inbound filters very quickly.
For now, I'm going to mark this as 'won't do', because we won't be striving for parity at present. If there are specific filters you'd like added to the dashboard, please post them as new feature requests and we'll investigate adding them (I do like the idea of the message being supported).
There's also scenarios where dashboard filters will exist that won't exist for inbound filters (e.g. we should have 'where affected user count is > x' or 'Comments = 0', that aren't individual crash report specific. This is another reason we're not going to strive for parity between the two features.
I hope that helps explain the differences, clarifies that you can achieve some of these on the dashboard already, and why they won't be the same set. I can tell you however that we have some improvements planned for the dashboard filtering that should expand the scope for them also :-)
Kind regards,
John-Daniel Trask
nathanielcook
Posted on
Sep 13 2016
Wildcards is the main feature we need. The user agents coming from our mobile app to our API contain stuff like MobileAppName/12345 (iOS,iPhone,9.3)
and MobileAppName/12345 (Android,Phone,MRA58K)
and we really need to be able to filter by "iOS" or "Android".
nathanielcook
Posted on
Feb 16 2017
I see this is partially implemented now as wildcards are now supported. The only other thing we really want is for user agent to appear in that dropdown!