[Bug]: Scanner query results page should expose to AMO admins which add-on versions were blocklisted by Mozilla

[abhn]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

Scanner query results page exposes a "was blocked" column. This includes versions blocklisted by both Mozilla and the developer.

For operational workflows, it is important to be able to differentiate between blocklisting actions performed by Mozilla vs the developer. An example usecase could be

• Operations team wants to assess the effectiveness of a scanner rule against false positives
• They run a scanner query rule to check all the versions that a rule matches (including previously disabled items, using the "Run on disabled addons")
• To determine the expected true and false positive ratio, it is important that they're able to check which add-on versions matched by the rule were disabled and blocklisted by Mozilla and which weren't
• Currently, the page only exposes if a version was blocklisted, and not if the version was blocklisted by Mozilla or developer.

Resulting added effort: This requires the ops member to open the add-on and manually check if the add-on was disabled for malware by Mozilla, or if the developer disabled their version voluntarily.

What did you expect to happen?

Scanner query results page should indicate if a version was blocklisted by Mozilla, and ops team should be able to filter add-ons based on this data. This will prevent ops team from having to open add-on review page to discover if the version was blocklisted by Mozilla or the developer

┆Issue is synchronized with this Jira Task

[diox]

I see the value of adding that, but for what it's worth, I don't think the distinction between the 2 is that relevant, and I'm not sure it's worth for Operations to spend much time trying to find out. Developers can't unblock something that was soft-blocked by their actions and users are still kept safe by soft-blocks, the only difference for them is that they can go through hoops to unblock...

[abhn]

I rewrote the ticket keeping in mind what was the problem I was trying to address with this issue. Please give it another look and see if it makes more sense. Thanks

[wagnerand-moz]

I am wondering how the ask is aligned with the use cases. Some mention blocked vs not blocked, which is already possible today. For the other, I am not sure if soft vs hard blocked is the same as blocked due to a developer vs Mozilla action. There might be some overlap, but there is no guarantee that a soft-block has always been caused by the developer. A hard-block always coming from Mozilla is probably true currently, but there are no guarantees built around that.

[abhn]

I think my title switch didn't save for some reason. The ask is to be able to differentiate (and filter) based on whether a version was (hard/soft, doesn't matter) blocklisted by Mozilla or anything else (could be: version not blocklisted, version blocklisted due to developer action etc).

A more nuanced filtering is probably useful, but for my specific use case, it isn't needed.