tkrop
commented
2 years ago Could be also seen as a kind of violation optimization, that is handled by the server. Violations are than aggregated outside the rule engine and translated into violations that allow multiple locations.
Current situation
When validating large APIs, you often get many similar violations, just for different locations. In the UI this currently looks like this (Nakadi's API used as an example):
This makes the list of violations quite long, while there essentially are only 11 different MUST rules violated here.
Suggestion
Violations with the same title (and rule) should be grouped together. When (as here) they also have the same detail message, we should just have a list of locations (+ a total count).
When they have different details (for cases where the details message is parameterized, like
scope ... does not match regex '^(uid)|(([a-z-]+\.){1,2}(read|write))$', it's a bit more complicated.Current state:
Simple solution
Just aggregate those with the exact same detail message), with a list of locations, leave ones with different details alone.
More complex solution
Have a second level aggregation by detail under the top-level aggregation. This likely needs a slight rearrangement, moving the rule link to the top:
(I've mocked up this by editing the DOM in Chromium's dev tools, with proper styling it can look better.)