It is no longer possible to filter hotspots like before, either through the web portal or the web_api calls, for instance, either by language or by rule key.
So if, say, I’m a developer who’s been assigned the task of examining all JavaScript hotspots, I have to scroll through all the Java hotspots, the HTML hotspots, the XML hotspots, etc., to find what I need.
Hello @MisterPi,
Thanks for the feedback. On purpose, we remove all filters that are available for Issues when Hotspots became an entity by itself. The idea was to simplify the workflow so that you as a developer think less about which filter to apply but instead start to focus on what is important, start the review process and learn/fix.
While I understand the need and I tend to think it would make sense to add a way to filter by language, I would like to understand from where this request comes from.
Did you get it from various developers or this is a personal need a security auditor is facing while performing an audit?
Thanks
Alex
The very purpose of a filter is to give you the ability to specify what is important and what is not important. For instance, an astrophysicist does an experiment involving the blue wavelengths of light from a star, and puts a blue filter on the telescope. Taking away a filter doesn’t let you “focus on what is important,” but does the exact opposite, by flooding you with superfluous information.
In our case, I can filter vulnerabilities by language, bring up, say, just the new Java vulnerabilities, send the URL to one of the Java developers and say, “please address these.” And I can generate a different URL for the JavaScript vulnerabilities and send that to a JavaScript developer. But I can’t do this with hotspots.
By the way, the hotspots tab on the web portal groups hotspots by review priority, so it appears the designers want at least some filtering, but this isn’t an option with the web_api function api/hotspots/search.