Klever

Pavel Andrianov wrote:

Now conclusions based on similarity are hard-coded: if a report is more than 0% similar to an existing mark, the mark is applied to the report, the report is shown as marked on the Job page and so on. For example, one does not consider a report with similarity 50% as a bug. There is no way to affect it: only one view on report page, where similarity may be disabled or enabled. For general user it is useful to have an option, what percentage of similarity should be treated, and this percentage should be applied to Job page, to Job tree page etc. Views on report pages may be also useful, so if I set marks application to 100% similarity by default, using special view on a some unsafe report I may also look on 50% similar marks.

Vadim Mutilin wrote:

Now we can't tell trusted marks with 100% similarity from suspicious ones with 50% similarity

Indeed there is the only corner case which is likely correct: marks can be automatically treated irrelevant when a similarity is 0 (also they are automatically treated irrelevant when attributes like verification object or rule specification don't match). All other cases in ideal need manual consideration and confirmation since a similarity of neither, say, 20% nor 100% guarantees nothing - error trace comparison criteria usually catch (much) more than intended and no one should rely upon them blindly. So the proper solution, confirmation, was proposed and implemented.

Unfortunately so called "general" users are actually lazy users which don't want to review associated marks carefully to perform proper marks and reports management (some marks can be duplicates, some require refinement, some similar reports can highlight tricky bugs in code and so on). Instead they want to do less and get nice reports faster. For such the users it should be personal, not global settings, perhaps even different for various jobs since sometimes they can spend a bit more time for more careful evaluation.
Pavel Andrianov wrote:

I do not know now should the option be an attribute of a user or, may be, a (user, job) pair.

From the one side this matches a current view conception (except for relations with particular jobs) when one sets up data representation in accordance with one's purposes. This is even partially implemented since at the unsafe page you can hide all associated marks with similarity between 0% and 100%. From the other side the situation is much worse since it isn't restricted just with simple data representation - caches should be (re)calculated in accordance with user specific settings. For instance, assume one will change its personal mark similarity acceptance range from default +0% to, say, 80%. Then for such the user all caches related with associated marks (e.g. total verdicts shown at the unsafes page and statistics on them shown at the job and jobs tree pages) should be calculated again and later corresponding cached data should shown individually for the given user. Likely this also can be treated as a view but more complicated than the existing ones.

Technically this is possible although looks to be quite hard for implementation since it touches many things. Philosophically this freedom will result in many difficulties from my point of view since different users will see various statistics. For instance, users with default +0% can see many incompatible marks in statistics and more unconsidered marks at unsafe pages. So, at least it looks like the similarity rate should be specified for particular jobs rather than particular users. Worse is that after some time a selected rate can become bad. For instance, one will select 80% and suddenly will get good statistics (which also doesn't necessary happen). Later new marks which aren't appropriate indeed can damage this statistics since they can have more similarity rate. So one still will require to do something with that mess and this can be even harder than moving in the only proper way mentioned above. Perhaps this doesn't matter much such the requested functionality is most likely useful to just quickly analyze verification results of some job and forget about these efforts soon as well as all other efforts made during previous analyses.

Vadim Mutilin wrote:

The priority should be high.

The solution isn't obvious while implementation looks to be hard anyway, so, I don't think that this should/will be implemented soon.

Vadim Mutilin wrote:

You suggest to change criteria that is completely another thing.

To be correct, it was suggested by Vladimir

This obviously follows your note that contradicts an original issue description:
Vadim Mutilin wrote:

100% guaranties that my criteria is totaly agree with the trace, so I can trust it if I trust the criteria. Thats what I want. The meaning of 20% I do not understand.

I see two ways to implement similarity management

1. with the help of parameterized criteria
2. new options for the view

Pavel, what do you think, does parameterized criteria fulfill similarity management request?

These ways are very different and both can be supported indeed. I will open a new issue myself. This one shouldn't be implemented.

Let's do this together with #9412 and #8338.

What exactly should be done here? I don't think calculating caches individually for each user is possible in near future, so both "the option be an attribute of a user or, may be, a (user, job) pair" are impossible.

Implemented in bridge-3.0.

I've done it for "user" settings only because of:

Unfortunately so called "general" users are actually lazy users

And it will be some more actions to set default threshold for each job.

The default threshold value will be used for inline created unsafe marks and will be set by default on fullweight mark creation page.

In master. It would be great if Pavel will try this feature and provide any feedback.