795037 - When app is blocklisted determine how to handle reviews

Status: RESOLVED FIXED

(Marketplace Graveyard :: Reviewer Tools, defect)

Description

[Rob Hudson [:robhudson]]

At the moment, the reviewer actions depend on the status (and other states) of the app. The status=BLOCKED isn't taken into account and should be.

CC'ing Andrew to help me determine the appropriate actions this needs to have.

Comment 1

[Rob Hudson [:robhudson]]

A few ideas...

* Add an icon where the other icons are when an app is blocklisted, so reviewers know.
* Presumably only already public packaged apps are blocklisted (otherwise, they'd just be rejected).
* If the dev submits a new update and the app is currently blocklisted, put it in the escalated queue so only Sr. Reviewers deal with these.
* On the review page, if the reviewer isn't a Sr. Reviewer, disable all review action buttons.
* When the new app is approved, automatically update the app status to PUBLIC.
  - Why I like this over setting the app to public first, and then approving the app is the window where the last version is now offered up in the mini manifest before the new version is.

Comment 2

[Andrew Williamson [:eviljeff]]

(In reply to Rob Hudson [:robhudson] from comment #1)
> * Add an icon where the other icons are when an app is blocklisted, so
> reviewers know.

An icon would be good.  Additionally On the review page itself I'd like the status to be BOLD red if its blocked, and maybe even a further warning near the approval box (where the 'other reviewer looking at this page' warning is)

> * Presumably only already public packaged apps are blocklisted (otherwise,
> they'd just be rejected).

Agreed.

> * If the dev submits a new update and the app is currently blocklisted, put
> it in the escalated queue so only Sr. Reviewers deal with these.

Agreed.  Would it otherwise be in the updates or submission queue though?  (The actions and compare, etc, would be different).

> * On the review page, if the reviewer isn't a Sr. Reviewer, disable all
> review action buttons.

I'd be tempted just to block the review page entirely with a warning (like the 'self reviews are not allowed' message)

> * When the new app is approved, automatically update the app status to
> PUBLIC.

Are there any other states it could have come from, pre blocking?  I can't think of any right now.

>   - Why I like this over setting the app to public first, and then approving
> the app is the window where the last version is now offered up in the mini
> manifest before the new version is.

Additional Concern/Query:
What happens to the existing versions?  If we've blocklisted the app then at least one of the approved versions is bad and leaving them 'approved' is risky (we might expose old versions in the future, or the developer might delete the post-blocked version and the latest version would be the bad one again).

Comment 3

[Rob Hudson [:robhudson]]

(In reply to Andrew Williamson [:eviljeff] from comment #2)
> An icon would be good.  Additionally On the review page itself I'd like the
> status to be BOLD red if its blocked, and maybe even a further warning near
> the approval box (where the 'other reviewer looking at this page' warning is)

Ok.

> > * If the dev submits a new update and the app is currently blocklisted, put
> > it in the escalated queue so only Sr. Reviewers deal with these.
> 
> Agreed.  Would it otherwise be in the updates or submission queue though? 
> (The actions and compare, etc, would be different).

Since it would be not the first version it would otherwise be in the updates queue.

> > * On the review page, if the reviewer isn't a Sr. Reviewer, disable all
> > review action buttons.
> 
> I'd be tempted just to block the review page entirely with a warning (like
> the 'self reviews are not allowed' message)

Ok. That works.

> Additional Concern/Query:
> What happens to the existing versions?  If we've blocklisted the app then at
> least one of the approved versions is bad and leaving them 'approved' is
> risky (we might expose old versions in the future, or the developer might
> delete the post-blocked version and the latest version would be the bad one
> again).

Hmm, yeah. The only way I can think to solve this is to mark all versions as "Disabled by Mozilla" so they can't be re-enabled and if the latest version is deleted they won't be eligible as a valid version.

I think I'll start filing bugs for each of these items and attach them to this one.

Comment 4

[Andrew Williamson [:eviljeff]]

(In reply to Rob Hudson [:robhudson] from comment #3)
> (In reply to Andrew Williamson [:eviljeff] from comment #2)
> > What happens to the existing versions?  If we've blocklisted the app then at
> > least one of the approved versions is bad and leaving them 'approved' is
> > risky (we might expose old versions in the future, or the developer might
> > delete the post-blocked version and the latest version would be the bad one
> > again).
> 
> Hmm, yeah. The only way I can think to solve this is to mark all versions as
> "Disabled by Mozilla" so they can't be re-enabled and if the latest version
> is deleted they won't be eligible as a valid version.

Sure, sounds good.

Comment 5

[Rob Hudson [:robhudson]]

All the dependent bugs were closed, so I'm closing this one.