486500 - Allow deletion of incomplete add-ons?

Status: RESOLVED FIXED

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

Description

[Fred Wenzel [:wenzel]]

A user approached me today asking how to delete their add-on. As usual, I mentioned the security risk from "stealing" the GUID, then helped the user by admin-disabling the add-on.

The add-on still seems to show up on his DevCP dashboard however, which makes little sense.

I can think of several possible solutions here:
a) allow deletion of add-ons that are still incomplete and have never been on the AMO site. This way, nobody ever downloaded it, and thus the GUID stealing risk does not exist here.
b) Do not show the user admin-disabled (status = disabled) add-ons in their dev CP anymore, or:
c) hide such add-ons by default and only show them in the user's dev cp at the click of a button.

CCing fligtar who may know more about the rationale behind (not) deleting add-ons and showing/not showing them to the author when disabled.

Comment 1

[Andreas Wagner [:TheOne] [use NI]]

Attachment: Screenshot of a dashboard with a disabled extension

The user that requested the deletion was me.
As Frédéric Wenzel already mentioned, my extension was still incomplete, so no harm, if I had the option to delete it. (I had to change the guid of the extension in the last second).

In the screenshot, you can see my dashboard with the disabled extension. I deleted the name before it was disabled, so it looks a bit confusing right now.

Comment 2

[Wil Clouser [:clouserw]]

If we allowed deletion of incomplete add-ons we'd have to track "ever complete" somewhere (like bugzilla does).  Now showing admin-disabled add-ons by default seems easier.  It could be confusing in some cases though, e.g. an author is on vacation and can't respond so we disable his problem add-on.  When he comes back he can't find it in his dev CP.

Comment 3

[Justin Scott [:fligtar]]

Admin-disabled add-ons look a bit nicer in the dashboard of the new tools and say that if you have any questions about why your add-on was disabled, to email amo-admins. I think it's important to show it there, otherwise it seems like a bug that the add-on just disappeared.

Comment 4

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

Perhaps you could add a checkbox or some option to hide disabled add-ons in the dev tools so that it's up to the user.

Comment 5

[Wil Clouser [:clouserw]]

I think admins should be able to delete add-ons for real or they can disable an add-on.  When an add-on is disabled it shouldn't show up for authors.

Comment 6

[Wil Clouser [:clouserw]]

Proposal:
- A user can delete their add-on if it's being used by less than 100 users, regardless of status.  After that the UI for deletion is greyed out with a reason that says why.
- Deleting an add-on is permanent and there is no undo.
- A user can elect to disable their add-on at any time.  This can be undone any time.
- An admin can permanently delete any add-on, regardless of users. (permission bit: Admin:DeleteAnyAddon)
- An admin can disable any add-on.  In that case the add-on can only be reenabled by an admin.  Chowse/Jorge can help us figure out the messaging for users and whether it should show up in their control panel by default. (permission bit: Admin:DisableAnyAddon)

Something else which isn't directly related but worth noting is that we do have the ability to blacklist add-on GUIDs right now, so if we need to prevent a GUID from appearing on AMO we can do so.

Comment 7

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

I think admin-disabled add-ons should be fully accessible from the developer hub. The add-on status should indicate that it has been disabled by an admin.

Regarding the messaging to users, I'm not sure if we should show something more than "add-on not found". Maybe something like "this add-on has been disabled by an admin. To learn more about it, contact us at <amo-editors>".

Comment 8

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

Not sure what the point of restricting a developer from deleting an add-on?  I understand that it can have some negative effects, but it is *their* add-on and it can be equally destructive to just delete the versions of said add-on which I don't believe is restricted.

Comment 9

[Justin Scott [:fligtar]]

Add-on deletion by developers is part of the new Dev Tools, as explained in the "Add-on Deletion" section of the spec: https://docs.google.com/Doc?id=dfntthnr_78f58ztkfz

Comment 10

[Wil Clouser [:clouserw]]

Thanks.  Kicking to 5.12.2.  DD is doing the deletion via the API, so I think this will fit in well.  This remains a P4.

Comment 11

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

Will do the backend once gko is done with his stuff.

Comment 12

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

Bump this into 5.12.3 since I'm waiting on a blocker.

Comment 13

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

http://github.com/jbalogh/zamboni/commit/3741c59