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

> 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.

DELETE FROM main WHERE id IN (20,21)

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?

> 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.

(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?

Effie has the same problem. Effie - what is your addon name(s) and new user account?

(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".

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

FYI, didn't work on this last night because of the server downtime. Moved this back to tonight.

(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.

(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.

(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

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.

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.

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.

*** Bug 281273 has been marked as a duplicate of this bug. ***

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

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.

*** Bug 310038 has been marked as a duplicate of this bug. ***

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?

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.

(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.

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?

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?

(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.

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.

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.

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]).

These were pushed about an hour ago - fyi.

*** Bug 316482 has been marked as a duplicate of this bug. ***