1122107 - Allow switching an add-on from Unlisted to Listed

Status: RESOLVED INCOMPLETE

(addons.mozilla.org Graveyard :: Developer Pages, defect, P2)

Description

[Wil Clouser [:clouserw]]

An add-on that moves from unlisted to listed will be short on required information -- You'll recall we skipped from step 2 to step 6 when they uploaded, bypassing all the details we normally collect when uploading.

If an author wants to become listed, we should mark the add-on as incomplete and kick them back to step 3 in the submission process - as if they were uploading it for the first time.  When they get to the end of the process they will need to choose a review path just like normal.

Comment 1

[Wil Clouser [:clouserw]]

Note that we'll need to get a new copy of the .xpi if their existing add-on uses a custom <updateURL>

Comment 2

[Mathieu Agopian [:magopian]]

For unlisted addons, we now go straight from a shortened step 3 (only name and summary are asked) straight to the last step, because the review path is chosen automatically: if it's a sideload addon, it'll go in the full review queue, if it's not, then it'll go in the prelim review queue (unless it passed the automatic validation, in which case it's automatically reviewed).

So, kicking them back to step 3 means they will:
1/ not have any automatic validation (this is expected I believe)
2/ need a run of the validator to make sure there's no custom <updateURL>
3/ if there is a custom <updateURL>, need a new version of the xpi (still making sure it's the same guid
4/ need to be reviewed again (even if they were already reviewed)

I'm concerned though about addons that use the custom <updateURL>: switching Addon.is_listed from False to True will mean that the addon (and all its versions) will be listed. So it means we'd need a new xpi for all the previous versions, right?

At that point, wouldn't it be easier (for us and for the dev) to simply submit a new addon?

Comment 3

[Wil Clouser [:clouserw]]

I don't think we should ever have add-ons with a custom updateURL on AMO.  So, switching to listed would require a new add-on, yes.  I guess I would disable all the old versions with a message saying why.

Jorge - any guidance here?

Comment 4

[Kris Maglione [:kmag]]

Any versions we publish for a listed add-on will need to go through the normal review and validation process. Since we don't review older versions, this means that any previously uploaded versions will have to be disabled.

The latest submitted version can go through the normal validation process and be added to the appropriate queue, if there are no validation errors. But I'd also be happy to just require the authors to upload a new version in all cases, since any previous versions will presumably have an illegal updateURL.

Comment 5

[Mathieu Agopian [:magopian]]

Attachment: Screen Shot 2015-04-17 at 14.56.31.png

Comment 6

[Mathieu Agopian [:magopian]]

Attachment: Screen Shot 2015-04-17 at 14.56.44.png

Comment 7

[Mathieu Agopian [:magopian]]

Here's an attempt at formalizing the bug:

In the devhub, in the "Manage status & versions" page of an add-on, there's the "add-on visibility" block that allows the change of status between listed, hidden or unlisted (see screenshot attached).

At the moment, when the "unlisted" radio button is selected (because the add-on was submitted as unlisted), the other two radio buttons are disabled. The "listed" radio button should be enabled (not the "hidden" one, it makes no sense to have an unlisted addon be hidden).

Once clicked, it should display a pop-in the same way it's already done when clicking on "hidden" (see screenshot attached). This pop-in should ask confirmation, and display one of two things:

Current version has a custom <updateURL>
----------------------------------------

Warn that all the current versions (but the last one) will be disabled, and that the missing information will be asked. The add-on will need to go through a review, even if it's already been reviewed as an unlisted add-on. Also, before the add-on can be listed, it needs a new version without the custom <updateURL>.
Maybe something along those lines (wording to be adapted ;)

"""
List Add-on

Listing your add-on will make it visible and distributed on this website. This means new versions will be automatically proposed to users.
This also means that:
1/ all the current versions but the last one will be disabled (they went through a simpler review than what's needed for listed add-ons)
2/ the add-on will go back to being unreviewed, and incomplete: it'll go back to step 3 (out of 7) in the submission process for missing information to be provided

This, however, will be possible only after you've uploaded a new version without a custom <updateURL> (link to mdn) in its install.rdf file.

Please upload a new version first, and then only change the add-on to be listed.

Cancel (we may also add a "upload new version" button here)
"""


Current version doesn't have a custom <updateURL>
-------------------------------------------------

Warn that all the current versions but the last one will be disabled, and that the missing information will be asked. Also, the add-on will need to go through a review, even if it's already been reviewed as an unlisted add-on.
Maybe something along those lines (wording to be adapted ;)

"""
List Add-on

Listing your add-on will make it visible and distributed on this website. This means new versions will be automatically proposed to users.
This also means that:
1/ all the current versions but the last one will be disabled (they went through a simpler review than what's needed for listed add-ons)
2/ the add-on will go back to being unreviewed, and incomplete: it'll go back to step 3 (out of 7) in the submission process for missing information to be provided

Are you sure you wish to list your add-on?

List Add-on or Cancel
"""

Clicking on "cancel" will simply close the pop-in and not change anything. Clicking on "list add-on" will
- update the addon.is_listed field to "True"
- disable the "unlisted" radio button (at least until bug 1122108 is implemented)
- enable the "hidden" radio button
- disable all the current versions but the last one
- update the addon.status to amo.STATUS_NULL
- remove all the devhub.models.SubmitStep above 3
- redirect to the SubmitStep 3

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

+1 on comment #4

Comment 9

[Rob Hudson [:robhudson]]

I wanted to point out that unlisted->listed, then listed->unlisted doesn't get the user back to where they started. If we mark all their old versions as obsolete I don't think we would be able to reverse this if they then decided to go back. I'm mostly bringing this up as an edge-case and wondering what should we do if the user treats this as a toggle to go back and forth?

Comment 10

[Kris Maglione [:kmag]]

I'd rather not make it too easy for developers to repeatedly switch back and forth. But, yeah, I'm not especially happy about that edge case either. At the very least we should probably log any status changes we make during the switches, so we at least have the data to revert them if we decide it's necessary.

Comment 11

[Mathieu Agopian [:magopian]]

Here's another idea, to simplify the whole process:

When the user clicks on "listed" (with the current status being "unlisted"), a popup is displayed saying:
"To switch from unlisted to listed, an add-on needs several things:
- a version that has no custom updateURL in its XPIs (link to MDN page)
- a license (link to the devhub "manage authors & license" page)
- optionally various other bits of information (link to the devhub "edit" page)
Please note that all the versions but the last one will be disabled. Also, the last version will go back to being unreviewed, and will have to go through a manual review again.

<Switch to listed> <cancel>"

If the "switch to listed" button is clicked, it'll
- make sure there's no custom updateURL in the XPIs of the latest version (if there's one, it should return with an error message)
- make sure a license is chosen (if not, it should return with an error message)
- disable all the previous versions
- set the last version to be unreviewed (if it was preliminary reviewed) or nominated (if it was fully reviewed)

Possible modifications to this proposition: allow the user to choose a review queue in the popup, before clicking on "switch to listed".


:clouserw :jorgev, thoughts?

Comment 12

[Kris Maglione [:kmag]]

I mostly like this idea, with some modifications.

• The copy needs some work. (I can do that)
• I definitely think we need to allow them to choose the review track. The differences between tracks for unlisted add-ons are only relevant to side-loading. They're much more important for listed add-ons.
• If the latest version fails validation with errors (e.g., it has an updateURL), we should give them the opportunity to upload a new version. I don't think it makes sense to require them to do that separately before attempting to switch.
• We should probably take them through the parts of the normal submission process that allows them to enter summary/description/categories...

Comment 13

[Mathieu Agopian [:magopian]]

yup, I think we can add two radio-buttons (or two submit buttons) for the user to choose which review queue.

Comment 14

[krupa raj[:krupa]]

I'd vote for not having this feature. If the developer chooses to have their add-on as "Unlisted", then they cannot switch to listed or hidden. I think the ROI on implementing this feature is not worth it since it adds a lot of complexity for a feature which won't be oft used.

We shouldn't be encouraging fickle behavior anyways :)

Comment 15

[Ignat Alexeyenko]

I've just destroyed my extension I was about to publish due to this. I was learning the Developer Hub front-end and clicked Unlisted - my assumption that I will make it Listed again when all the data is filled in. 

Please remove this feature from UI as other developers will accidentally click this button and have the same experience.

I can not submit another add-on as it uses the same add-on key: it's prohibited.

Now I'd like to make an add-on listed and the further steps are not clear to me - please suggest a workaround.
Will deleting the add-on completely & submitting it again to AMO using the same key fix the problem?

P.S.: Chrome Web Store has Unlist feature that allows to hide the extension (with an option to publish it again later). This makes current AMO Developer's Hub 'Unlist' options more confusing for developers, who's publishing a Mozilla Add-on.

Looking forward to hearing from you.
Thanks!

--
Cheers,
Ignat.

Comment 16

[Jorge Villalobos [:jorgev] (he/him)]

There's an explanation of the process here: https://developer.mozilla.org/en-US/Add-ons/Distribution

If you need to switch from Unlisted to Listed, you need to delete your add-on and then give us the add-on ID so we can clear it from the DB and you can use it again.

Comment 17

[Tom Brückner]

This is very confusing. I submitted my add-on accidently without listing, and now I am completely stuck. How can I give you the add-on ID of my plugin to clear it from the DB?! If I try to upload a new version, I always get the duplicate ID error.

Comment 18

[Tom Brückner]

As a side note. The docs say:

> An add-on can be changed from Listed to Unlisted and viceversa, if you change your mind. You should know 
> that if you switch from Listed to Unlisted, your current users won't be automatically migrated to the 
> unlisted versions of your add-on. Switching from Unlisted to Listed is easier because Firefox will check 
> for updates on AMO if an add-on doesn't have an updateURL in its install manifest.

This sounds as if it is very trivial to change your mind later.

Making it even worse, the next section states:

> After accepting the Developer Agreement, you'll be asked if you want to list your add-on on AMO.
> Make sure you choose not to list it.

I understand this as a clear recommendation to not list the add-on if uploading it for the first time.

I think there should be a clear warning on the plugin submission dialog that it is *not* trivial to change your mind afterwards. At the moment, I have to admit that I have absolutely no idea how I can get may add-on back to AMO. Every time I try to upload it, I get this duplicate id error. But the id is not set anywhere in the package.json. So how on earth does the signing tool even detect and select the id?! Very confusing, and not a good developer experience.

Comment 19

[Jorge Villalobos [:jorgev] (he/him)]

The "Make sure you choose not to list it" is under the Unlisted section, so it's just meant to tell you what to do if you don't want your add-on to be listed, not a general recommendation.

To move from unlisted to listed (I understand that's your situation), all you need to do is delete your add-on and upload it again. You don't need to send us the ID and have us clear it manually anymore. You should be able to submit again after deleting it. If that doesn't work, please email amo-admins AT mozilla DOT org and we'll help you.

I agree it's a bad experience, and we'll fix it as soon as we can. At the moment we're working on other priorities.

Comment 20

[Tom Brückner]

Thanks for your quick reply.

> The "Make sure you choose not to list it" is under the Unlisted section, so it's just meant to tell you
> what to do if you don't want your add-on to be listed, not a general recommendation.

Yes, I got this now, but only after I fell into the trap and carefully re-reading the sections. I think it would be much better if you included a warning in the submission dialog (at the moment, it only includes a "?"-Link, but this does not include a hint about this as well).

> To move from unlisted to listed (I understand that's your situation), all you need to do is delete your 
> add-on and upload it again.

I tried this. But afterwards, I wasn't able to upload a signed XPI anymore, because I always got the duplicate ID error message. It only worked if I generated a normal (unsigned XPI), but this plugin could not be downloaded from the portal until it was accepted by your staff. I already sent a mail to amo-admins, and I got a response as well. So thanks!

> I agree it's a bad experience, and we'll fix it as soon as we can.

Great to hear this. Keep up the good work!