✨ dismissal of incidents

[shawn-hurley]

Tried to capture the changes across the projects, keeping the logic for dismissal in the analyzer and adding the UI/UX for how a user could use this feature

[djzager]

A couple of things:

1. I'm genuinely curious how much value we would "lose" by simply allowing users to dismiss at the rule level. This may be a declaration of ignorance but it isn't immediately obvious scenarios where a particular rule generates issues that must be fixed at the same time as ones that don't need to be addressed.
2. I wonder if we could perform the dismissing/filtering as a post-analysis step. My argument for this perspective is that I view this concern as a purely presentation layer concern. That is, at the analyzer level, these are absolutely still incidents; they just happen to be ones we don't want to see in analysis reports in the Konveyor UI or static-report.

There are some implications to these thoughts that I don't want to ramble on if I'm heading in the totally wrong direction.

[shawn-hurley]

I'm genuinely curious how much value we would "lose" by simply allowing users to dismiss at the rule level. This may be a declaration of ignorance but it isn't immediately obvious scenarios where a particular rule generates issues that must be fixed at the same time as ones that don't need to be addressed.

You know, this is a good question that I don't know if I have an answer too.

One thing that I was thinking of is work at the lowest level to give users the most flexability, and we could add a "bulk" update based on ruleID as a follow up. Now this doesn't mean that it is correct by any stretch of the imagination.

Something that I was thinking about was a use case like local-storage. They are mandatory issues, that tell you to fix something, but let's say you have two use cases for local storage. In one use case, you are using a local file for configuration, this would most likely be a configmap in k8s and still use local storage. But let's say that you are also using a cache of data over local storage, this probably should be solved.

So for the tackle test app case, you probably across the entire portfolio want to disable that particular incident for the application config, because you plan to solve that with a configmap across the entire portfolio.

Just a thought though, wondering if that even makes sense.

[shawn-hurley]

I wonder if we could perform the dismissing/filtering as a post-analysis step. My argument for this perspective is that I view this concern as a purely presentation layer concern. That is, at the analyzer level, these are absolutely still incidents; they just happen to be ones we don't want to see in analysis reports in the Konveyor UI or static-report.

I agree they are still incidents, but because we have two layers (and potentially more with the specific language builds) doing this, I figured two things:

1. That adding it into the analyzer means a single implementation that everyone gets to use.
2. Making it a first class citizen (like we did with insights for instance) gives the output of the analyzer more structure to get what you really want. Think about the Kai case, where they really just use the output of the analyzer. If in a company they want to ignore certain specific incidents (say similar to the local storage outlined above) then you probably want this to live in the analyzer.

The analyzer could do this as a post process OR it could just add a field on the incidents instead of making a whole new list. I leaned to the whole new list because it "feels" like something you would want to see at the top level. I could be convinced that it should be at the lower level and just be a field on the incident, but I can't think of a compelling reason at the moment.

Does that make sense? Should I add any of this to the enhancement?

[eemcmullan]

Would this make more sense as a subcommand for analyze? It is only relevant to the analyze command, and that way it wouldn't be on the same level as kantra transform and kantra version etc..

[shawn-hurley]

I am wondering how important that is, if you feel strongly I can change.

[eemcmullan]

No strong feelings

[djzager]

LGTM

[jortel]

LGTM