When app is blocklisted determine how to handle reviews

RESOLVED FIXED in 2012-10-11

Status

Marketplace
Reviewer Tools
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: robhudson, Assigned: robhudson)

Tracking

2012-10-11
Points:
---
Dependency tree / graph

Details

(Assignee)

Description

5 years ago
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.
(Assignee)

Comment 1

5 years ago
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.
(Assignee)

Updated

5 years ago
Target Milestone: --- → 2012-10-04
(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).
(Assignee)

Comment 3

5 years ago
(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.
(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.
(Assignee)

Updated

5 years ago
Depends on: 797026
(Assignee)

Updated

5 years ago
Depends on: 797028
(Assignee)

Updated

5 years ago
Depends on: 797030
(Assignee)

Updated

5 years ago
Depends on: 797031
(Assignee)

Updated

5 years ago
Depends on: 798154
(Assignee)

Updated

5 years ago
Target Milestone: 2012-10-04 → 2012-10-11
(Assignee)

Comment 5

5 years ago
All the dependent bugs were closed, so I'm closing this one.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.