If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Users can delete their account when they are the only owner for an extension

RESOLVED FIXED in Future

Status

addons.mozilla.org Graveyard
Developer Pages
--
critical
RESOLVED FIXED
12 years ago
2 years ago

People

(Reporter: ASANO Naoyuki, Assigned: morgamic)

Tracking

unspecified
Future

Details

(URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; ja; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Win98; ja; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

The author wanted to delete his old extension "Content Holder".
So he deleted his UMO account, but the extension remains.

Reproducible: Always

Steps to Reproduce:
1. The author created a new UMO account by his another e-mail address, and he added some extension.
2. Then he remember he had an old UMO account by his old e-mail address.
3. He got a new password of an old account by "Reset Your Password".
4. He logged into UMO and tried deleting his old extension, but he couldn't.
5. Then he deleted his old account to delete his old extension.

Actual Results:  
The extension "Content Holder" remains with no author.

Expected Results:  
The extension "Content Holder" should be deleted.

The author's name: SHIMODA Hiroshi
The author's e-mail address: piro@p.club.ne.jp

Comment 1

12 years ago
> Content Holder 0.2.2004052301, by , released on June 11, 2004
https://addons.mozilla.org/extensions/moreinfo.php?id=20
> ContextMenu Extensions 3.1.2004052301, by , released on June 11, 2004
https://addons.mozilla.org/extensions/moreinfo.php?id=21

These extensions above are owned by the old account.
Now, they have no owner.

Comment 2

12 years ago
DELETE FROM main WHERE id IN (20,21)
Assignee: Bugzilla-alanjstrBugs → morgamic
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 3

12 years ago
It would be better to update his relationship with his existing extensions.  Would it be okay to associate his new login/email with his old extensions?
Status: NEW → ASSIGNED

Comment 4

12 years ago
> Would it be okay to associate his new login/email with his old extensions?

I'm okay.

However, of course, I wish that the UMO becomes avoiding same troubles like this.
(Assignee)

Comment 5

12 years ago
(In reply to comment #4)
> > Would it be okay to associate his new login/email with his old extensions?
> I'm okay.

Does this mean you want the extensions deleted, or that you're okay with associating your new email with the old extensions?
(Assignee)

Comment 6

12 years ago
Effie has the same problem.  Effie - what is your addon name(s) and new user account?
Summary: Cannot delete old extension when delete the author's UMO account → Users can delete their account when they are the only owner for an extension

Comment 7

12 years ago
(In reply to comment #5)
> Does this mean you want the extensions deleted, or that you're okay with
> associating your new email with the old extensions?

It will help me that those old extensions are associated to my current account "piro@p.club.ne.jp".
(Assignee)

Comment 8

12 years ago
Okay guys, this will get fixed tonight.  Thanks for your patience.  :)

Just noting -- Effie's extensions:
https://addons.mozilla.org/extensions/moreinfo.php?id=1893&application=firefox
https://addons.mozilla.org/extensions/moreinfo.php?id=1894&application=firefox
(Assignee)

Comment 9

12 years ago
FYI, didn't work on this last night because of the server downtime.  Moved this back to tonight.
(Reporter)

Comment 10

12 years ago
(In reply to comment #9)
> FYI, didn't work on this last night because of the server downtime.  Moved this
> back to tonight.

When do you fix this?
And how do you fix this fundamentally?
I think AMO should not allow to delete their account when they are the only owner for an extension.

Comment 11

12 years ago
(In reply to comment #10)
> (In reply to comment #9)
> > FYI, didn't work on this last night because of the server downtime.  Moved this
> > back to tonight.
> 
> When do you fix this?
> And how do you fix this fundamentally?
> I think AMO should not allow to delete their account when they are the only
> owner for an extension.
> 

I think exactly the opposite. The extension publisher should be free to leave the umo as soon as he or she wants to. When an author choose to leave the umo, his/her extension must be removed immediately. Mozilla is not a gangster and it should not hold authors or content as hostage against a person's wish.


 
(Reporter)

Comment 12

12 years ago
(In reply to comment #11)
> When an author choose to leave the umo, his/her extension must be removed immediately.
> Mozilla is not a gangster and it should not hold authors or content as hostage against a person's wish.

morgamic didn't agree with that when I talked with him.
Here's the log.

02:38 >nasano< IMHO, when they delete their own account, their extensions should be deleted. 
02:41 <morgamic> i don't think that's right.
02:41 <morgamic> that gives users too much control over a consumer base they are not responsible to.
02:42 <morgamic> so say if john smith deletes his account, but his extensions are installed on 500 end-user browsers
02:42 <morgamic> that gives john smith the power to say, "i'm no longer going to support this, and nobody ever will"
02:47 <morgamic> so it's not that simple
02:47 <morgamic> that's all i'm sayin
02:48 <morgamic> even if a user decides they don't want to work on their extension anymore, it doesn't mean they should have the power to abandon the user base and leave people hanging
02:48 <morgamic> i'd prefer that outdated or abandoned extensions be available to be picked up by people who want to continue development
02:48 <morgamic> the way mozdev does it
02:51 >nasano< So, you think it's ok to exist extensions owned by nobody.
02:52 <morgamic> only if there is a precedent, and if the application properly displays that status
02:52 <morgamic> so that means that developers would have to agree that, "yeah if it's abandoned someone else can pick it up after ___ months"
02:52 <morgamic> and the site should not freak out when the authorxref doesn't have a matching entry for main.ID
02:52 <morgamic> in the current system, that's not the case

Comment 13

12 years ago
If we're going to go into policy, then this is a duplicate of bug 278234.  If we're talking about whether the function is broken, then this bug should be about that.
(Assignee)

Updated

12 years ago
Severity: major → critical
Target Milestone: 1.0 → 2.0
This bug should not be about policy, just the mechanism, but that means it's not necessarily a bug (since the correctness of the behaviour depends on the policy resolution).  Reducing severity.
Severity: critical → normal
Target Milestone: 2.0 → Future
Depends on: 278234
No longer depends on: 278234
Blocks: 278234
(Reporter)

Comment 15

12 years ago
I think there are two situations.

  (1) I won't maintain my extension. Let's delete my account. Bye-bye AMO! Sayonara!!
  (2) I've created a new version of my extension. Let's add to AMO...
      What's wrong? I can't add my new version!
      Wait a minute... I remember I added my old extension to AMO by old e-mail address.
      If I delete my old AMO account, I may add new version.
      Let's delete my old AMO account... Oops.

bug 278234 is related to (1), but comment #1 is related to (2).
An author of comment #1 has a new version, but he can't manage his own extension.

AMO should warn when an author deletes an account like this:

  If you delete your AMO account, AMO won't delete your extensions.
  Are you sure?

And I think this bug is critical.
Severity: normal → critical
(Assignee)

Comment 16

12 years ago
*** Bug 281273 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

12 years ago
*** Bug 297443 has been marked as a duplicate of this bug. ***

Comment 18

12 years ago
The real problem is database integrity.  We're doing lookups for authors and not finding them.  

We could create a user named "Unmaintained"

Delete my account ...
   Remove my submissions?
   Move my submissions to Unmaintained

To see the list of unmaintained addons, you just list items belonging to the author named "Unmaintained"

We will need a mechanism to allow volunteers to take over items.  But that would be dependent on bug 278234.

I think that we need to establish the policy before we try to code the solution. 

Comment 19

12 years ago
*** Bug 310038 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 20

11 years ago
Created attachment 224724 [details]
Example of delete message.
Attachment #224724 - Flags: first-review?
(Assignee)

Updated

11 years ago
Attachment #224724 - Flags: first-review? → first-review?(shaver)
Comment on attachment 224724 [details]
Example of delete message.

We should probably say "the only author for one or more add-ons", for if/when people have multiple authors associated.

Can we provide a list of the add-ons in the message?
Attachment #224724 - Flags: first-review?(shaver) → first-review?
(Assignee)

Comment 22

11 years ago
Created attachment 224725 [details] [diff] [review]
Code for author check on user deletion.

Patch for adding the check on authorxref -- right now it's about as simple as it can be... I didn't see a reason to overcomplicate things.
Attachment #224725 - Flags: first-review?(shaver)
(Assignee)

Comment 23

11 years ago
(In reply to comment #21)
> Can we provide a list of the add-ons in the message?
Sure, np.  Will resubmit when I have that working.

(Assignee)

Comment 24

11 years ago
Created attachment 224735 [details]
Updated example.
Attachment #224724 - Attachment is obsolete: true
Attachment #224724 - Flags: first-review?
(Assignee)

Comment 25

11 years ago
Created attachment 224738 [details] [diff] [review]
Updated patch to include links to add-ons.
Attachment #224725 - Attachment is obsolete: true
Attachment #224725 - Flags: first-review?(shaver)
(Assignee)

Updated

11 years ago
Attachment #224735 - Flags: first-review?(shaver)
Attachment #224735 - Flags: first-review?(shaver) → first-review+
(Reporter)

Comment 26

11 years ago
I think morgamic's patch is great.
And, Do you have any plan to fix database of these orphaned extensions?

  https://addons.mozilla.org/firefox/20/
  https://addons.mozilla.org/firefox/21/
  https://addons.mozilla.org/firefox/1893/
  https://addons.mozilla.org/firefox/1894/
  https://addons.mozilla.org/firefox/1144/
  https://addons.mozilla.org/firefox/1185/

Should I submit it as a new bug?
(Assignee)

Comment 27

11 years ago
No, I don't think we need an additional bug.  I actually worked on a db script that can do a nubmer of things depending on what is prudent.  So using a left join we can easily get the id's of the add-ons who have no author.

I worked on making queries for clearing out all dependencies -- versions, categoryxref, authorxref, approvallog, downloads, reviews, previews, feedback.

The problem for me was -- do we remove all main entries that have no respective author _to this point_ or do we just assign them to nobody?

In most cases the existing non-author records have alternatives that are published and working properly -- the total is about 60, with dupes.  So all-in-all it is probably roughly 35 we're talking about, and nothing high-traffic.

What do you guys think?

Comment 28

11 years ago
(In reply to comment #27)
> The problem for me was -- do we remove all main entries that have no respective
> author _to this point_ or do we just assign them to nobody?
> 
> In most cases the existing non-author records have alternatives that are
> published and working properly -- the total is about 60, with dupes.  So
> all-in-all it is probably roughly 35 we're talking about, and nothing
> high-traffic.
> 
> What do you guys think?
> 
Is there a way we can get people with the old unmaintained add-ons installed to automatically be prompted to download the new one even though it has a different listing on AMO? We'd also want to forward any requests for the url of the old add-on (eg. links from other sites) to the url of the new, maintained one. 

If all that was possible, it's be great to do if (add-on has newer, maintained version) then delete it and point people over there, else, assign to nobody@mozilla.org

(In reply to comment #24)
> Created an attachment (id=224735) [edit]
> Updated example.
> 
With this patch.. we might want to tell the developer what this means in terms of the license for their add-on. 

--Note that below this line is speculation and I'm not a lawyer--
It's all very grey at the moment, but as far as I can tell.. original add-on authors still retain copyright over add-ons they host on amo (unless there's a notice somewhere when they sign up or upload? not that I know of though) so if they were to abandon it to nobody@mozilla.org then they'd have to release their copyright or something, and we'd want to get some legal confirmation about the proper way to go about that. 
(Assignee)

Comment 29

11 years ago
I'm going to bite the bullet and delete orphans up to this point, because most of them are duplicates and the "nobody@mozilla.org" option never existed so retro-actively figuring out who wants to do what is not really worth it.

Patch has been checked in, though I still have to post the SQL for killing the orphans and verify that it works in staging.
Can you extract the orphans into a CSV or something, so that we can fish data out later if we need it?  Otherwise sounds like a find plan.
(Assignee)

Comment 31

11 years ago
Created attachment 225644 [details]
DELETE statements for all data that has no owner.

This is straightforward -- used an IN() for explicit IDs since you can't delete from main or authorxref with the subselect to find the mismatches, which is:

select main.id from main left join authorxref on authorxref.id=main.id where authorxref.id is null order by name asc;

I have corresponding select * from ____ for each delete statement stored in .csv's in case we need to restore as needed.  Last resort, there's always the server backups.
(Assignee)

Updated

11 years ago
Attachment #225644 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 32

11 years ago
Alright, the code fix for the functionality piece is completed, so this can be resolved.  The push to production should happen before the end of the week.

See bug 341588 for info on the SQL update (attachment 225644 [details]).
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 33

11 years ago
These were pushed about an hour ago - fyi.

Comment 34

11 years ago
*** Bug 316482 has been marked as a duplicate of this bug. ***
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.