Adding a new listed version to an addon with unlisted versions forces dev to finish

[eviljeff]

Scenario: An add-on has one or more unlisted versions. The developer starts to add a listed version and gets to the step after upload where they are required to provide some metadata (version license; add-on categories; add-on summary) to make the add-on complete enough to be sent for review. The developer changes their mind about adding the version. (Too bad!)

Once an add-on has a listed version attached to it we force the developer to supply the metadata required by redirecting all devhub pages under that add-on to the submission flow. We do this because it's otherwise difficult to signal to the developer it's necessary to proceed - files/versions are created in AWAITING_REVIEW state (there is no Incomplete status for a file). There is no cancel in the process - to regain normal add-on edit access the page must be filled in.

Possible solutions:
A) Nothing! There are only 3 required items; summary is probably there already so it's a matter of clicking a random category and choosing a random license from the list.

B) Add a cancel button that would make the version STATUS_DISABLED and adjust the logic to only redirect when there is a non-disabled listed version. Note this would mean the developer couldn't try again with the same version unless we keep the 'request review' function and make it handle this case.

C) Stop redirecting all the devhub pages into the flow. This would likely mean a lot more confused developers who don't understand why the listed version they submitted isn't going to be reviewed even though we're telling them its awaiting review. So we would need some UX changes in devhub with a clear call to action for the developer, both in the my submissions list, and in versions & status in the add-on page.

[eviljeff]

@jvillalobos for his thoughts

[eviljeff]

Because this could change how the developer is able to manage submissions it's a semi-blocker on #3925 and #3915 too.

[jvillalobos]

Option B makes the most sense to me.

We're not telling the developer anything after they're redirected to the submission flow, right? Maybe we should add a message to that step explaining why they ended up there.

[eviljeff]

In mozilla/addons-server#4486 I've done B, with a message you'd see if we redirected after you requested a review.
But, to make this work I changed the request review and cancel review functions. This is the rough flow:

1. start submitting a listed version
2. get to details step in the process. There is a 'cancel review and disable version' button. If this is pressed then the newly uploaded version's files are set to STATUS_DISABLED.
3. User is directed to the status and versions page in the devhub listing.
4. The 'request review' link under the latest version is now available (even though the version is STATUS_DISABLED)
5. if 'request_review' is selected the version's files are changed to STATUS_AWAITING_REVIEW again.

So, the cancel review function now sets the files to STATUS_DISABLED, as well as possibly resetting the status if it was STATUS_NOMINATED.
Also, the request review function is now available for STATUS_DISABLED files (because of the changes to cancel review). A side effect is it's now possible to re-request review for a rejected version.

Question:
Should the nomination date be reset?

[jvillalobos]

I think the nomination date should be reset, since you're re-nominating a file that was either rejected or disabled by the developer. @wagnerand and @kewisch, do you agree?

[kewisch]

Yes, I also think nomination should be reset.

[ValentinaPC]

Should the nomination date be reset?

I'm not sure about what this means?
But the new "Cancel Review and Disable Version" appears at the details step of add-on submission and works as expected.
Also clicking the "Request Review" link from "Manage Status & Versions" page redirects to add-on submission details page.
Postfix screenshots:

[eviljeff]

Should the nomination date be reset?

I'm not sure about what this means?

if an add-on that was previously nominated has that request cancelled, and then requested again, it get a new date so goes to the back of the queue.

It can be tested by finding an add-on that was previously rejected (before today makes it easier) and doing 'request review' on it, then checking the reviewer tools and seeing it at the bottom of the queue because it's only been nominated just now..

[ValentinaPC]

There is only one problem: rejected add-ons don'tt have a "request review" link, or am I looking in the wrong place?
Please see the screenshot:

Thanks!

[eviljeff]

might be the same problem as #3961

[ValentinaPC]

Verified as fixed on AMO-dev FF51(Win 7).
The nomination is reset - after clicking on "request review" link from a rejected versions, the add-on is listed in Reviewer Tools at the end of the queue.
Postfix screenshot:

@eviljeff :

1. if user does not use the red button to cancel the brakes the submission, same thing as before happens. This is ok, no? I mean, that is why the button was added: to use it.

2. If is the case of first unlisted-> second listed with "Cancel Review and Disable Version" button clicked for the listed version - accessing My Submission page will display the add-on as incomplete with "Resume" and "Cancel" links - do we want this for mixed versions?
   Thanks in advance!

[eviljeff]

Yes, the developer must either continue with adding details or cancel the listed submission to be able to access the add-on edit pages again.

The add-on should be shown as incomplete when it has a listed version that isn't approved, or awaiting review, yes.

[ValentinaPC]

The add-on should be shown as incomplete when it has a listed version that isn't approved, or awaiting review, yes.

No matter if it has or not an unlisted version, together with the listed one?

[eviljeff]

unless someone says it should be otherwise, yes :)