We are not intending to change how the existing (static) grouping functionality works (we don't have a good grasp of the existing use cases). We would just allow showing the static groups in a new tab, like in the screenshot.

As for adding vuln_id_from_tool to the "group findings by" dropdown: indeed, we would get the same groups as with the proposed dynamic grouping. One difference is that dynamic grouping can apply to any finding (we're under the impression that the static groups are assigned during import), and isn't saved to Postgres; this means that people already using the static grouping can still look at different dynamic groups without changing the static grouping.

But now that you mention it, we could drop the dynamic grouping functionality altogether and instead add a vuln_id_from_tool option to the dropdown. It would still be useful to add the new "Group/Problem" tab to make the groups easier to browse (OpenVAS scans often include hundreds of different vuln_id_from_tool values).

ok so your dynamic grouping is more like a "view"? I am asking because having a feature that stores extra/custom data in redis sounds like something the Defect Dojo team wouldn't want to accept right now because of the added complexity. If it is a "view" thing, could it just render the view on the fly?

Something I have been thinking about for grouping is whether we should allow parsers to have more control over how they group findings, especially if the findings have endpoints. This grouping could be flexible i.e. controlled by the user via (parser specific?) import parameters.

I think adding vuln_id_from_tool as (static) grouping option to the dropdown could get merged upstream. I was considering asking the community if there is a need for / value in having more options in the dropdown.

We do build the groups on the fly if they're not already cached in Redis. The caching is just so we don't need to rebuild the Groups every time (could get expensive if there are many Findings?), or whenever the user clicks on a Group to get the list of Findings in that group.

Something I have been thinking about for grouping is whether we should allow parsers to have more control over how they group findings, especially if the findings have endpoints. This grouping could be flexible i.e. controlled by the user via (parser specific?) import parameters.

This is in line with our proposal. In our proposal, we plan to allow the creation of dynamic groups by different fields in the Finding model. For example: Finding.vuln_id_from_tool, Finding.cve, Finding.endpoints (which would result in one group of Findings per distinct set of endpoints), Finding.severity, and Finding.mitigation could be useful fields to group by. So if the parser already fills in these fields, users would get the ability to build the dynamic groups.