Closed Bug 372852 Opened 17 years ago Closed 16 years ago

Some Extensions don't have any categories

Categories

(addons.mozilla.org Graveyard :: Administration, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Gijs, Assigned: baz)

References

Details

Because the available categories got shuffled a bit, a bundle of extensions (example in URL) don't have categories anymore. This has caused some problems in the past, and right now the first thing I noticed was that the "Find similar addons" part is empty. I'm assuming we could either send mail to all the authors who don't have a category for some of their extensions yet, or add some ourselves.
Mike, now that AMO has launched, would it be reasonable to send mail to all the add-on developers that own extensions without categories in the new category system to update their extension? I think this is preferable to just waiting for them to figure it out themselves (afaik this specific change was not announced), from a usability point of view - the "Find similar addons" being empty and the fact that extensions won't appear when users browse all the categories is bad UI, imho.

If sending mail to just the 'right' devs is too hard, I could live with an announcement to all developers as well. Thoughts?
I'd be fine mentioning it in a mail-out to developers.  We should do one to cover a bunch of Remora stuff, probably at the beginning of next week or end of this one.
We should probably finish up 373923 first, so we can add some links to the email.
Before sending email to all devs asking them to choose a category I suggest fixing 379144.
"SELECT COUNT(addons.id) FROM addons LEFT JOIN addons_tags ON addons.id = addons_tags.addon_id WHERE addons_tags.addon_id IS NULL;" says there is currently 107 add-ons without a category.  I'd estimate about 30% of those can't have categories because their applications don't have any.

There are also the ~2900 add-ons that are in Miscellaneous categories that we should encourage to move to more appropriate categories, or if they are already in one, drop the miscellaneous tag.  Maybe a requirement that you're either in a set of other categories or you're in Miscellaneous, but not both?
Wil: does the "no categories" include extensions only in categories that no longer exist, such as XUL Applications? :-)
(In reply to comment #6)
> Wil: does the "no categories" include extensions only in categories that no
> longer exist, such as XUL Applications? :-)
> 

Nope.  I moved the categories that I could in a similar fashion to what's on the bottom of this page ( http://wiki.mozilla.org/index.php?title=User:Shaver/Remora_Categories&oldid=48551 ).  Add-ons that were in categories that were removed (like XUL Applications), got dropped in the Misc. category.
So ChatZilla's in the social communication thingummywhatsit now, but we did that manually. How bad is the situation elsewhere? (I can't query the SQL myself and don't much fancy trying to randomly look for add-ons without categories...)

The "either misc. or some other set, not both" idea seems good, though I would also stop people from using more than, say, 3 categories, or people'll just spam by using every single category they can think of (without making it too obvious by using all categories, I hope, but perhaps people are stupid enough to try that, too). Food for a different bug, though.
Depends on: 396742
Target Milestone: --- → 3.2
Assignee: nobody → basil
OK, I used variations on the SQL from comment 5 to generate a list of problematic addons and here's the result. There were 145 initially.

- Some were re-assignable via the admin UI
- 23 were search engines and the categorization of those are awaiting resolution on bug 408525
- Some were dictionaries which don't have categories
- Some were themes. I couldn't use the admin UI since it complained with the following error: "No categories available for this add-on type". Here is the list of AMO IDs:  1206, 1749, 3097, 3480, 3489, 3551, 3798, 4013, 4064, 4308, 4309, 4313, 4314, 4361, 4367, 4375, 4378, 4380, 4446, 4447, 4475, 4509, 6039. Note that some of these lack authors and many seems to be dups of entries already in the database.
- Many of these, extensions and themes are disabled or incomplete.
- Some were extensions. The following exhibited the "No categories available for this add-on type" error:  1151, 1229, 1309, 1636, 2193, 2638, 2802, 2835, 2940, 2988, 3080, 3221, 3244, 3258, 3278, 3305, 3306, 3327, 3515, 3531, 3534, 3537, 3538, 3725, 3742, 3782, 3897, 3917, 3920, 3989, 4054, 4059, 4060, 4061, 4062, 4137, 4179, 4333, 4408, 4409, 4464, 4486, 4488, 4491, 4537, 4593. Similarly, many didn't include authors.
- Some of them have the same name - e.g. 4059, 4060, 4061, 4062. Does this cause problems?
- Here are the add-ons (type: extensions) with no name - 4593, 4939, 4942, 4950, 4986, 5019, 5078, 5319, 5481, 5514, 5622, 5652, 5654, 5672, 5682, 5708, 5822, 5922, 5969, 5987, 6085, 6090, 6102, 6172. Could this be caused by errors in install.rdf or perhaps because of the Remora migration. If so, shall we create a new bug to have AMO check the install.rdf and ensure that there's a name specified?
- We probably should run another query and ensure that all add-ons have authors associated with them.

I can't do any more fixes myself on this bug so re-assigning to fligtar for triage and advice.
Assignee: basil → fligtar
Depends on: 408525
The "No categories available for this add-on type" is a bit misleading. Categories are keyed off of an add-on type and an application. The error in this case is that because all of those add-ons (at least all the ones I tried) are incomplete and don't have an target application like Firefox associated with them. That's probably why they are are incomplete - they aborted before step 3 of the upload process.

There's not really anything we can do about these, and they aren't showing up anywhere so they're not really hurting anything that I can think of. This is the same deal with the search engines - because search engines don't have an application associated with them, they don't have any available categories listed.

All of the no-name entries I checked out were also incomplete or disabled, so they shouldn't be hurting anything either. So I'm not sure where this bug should go or what the problem is.
No longer depends on: 396742
Retargeting for v3.4. Not critical, this is a cleanup task to deal with the no authors situation
Target Milestone: 3.2 → 3.4
Assignee: fligtar → basil
Target Milestone: 3.4 → 3.4.1
OK, I've cleaned up as much as I could using variations on

SELECT addons.id FROM addons
LEFT JOIN addons_tags ON addons.id = addons_tags.addon_id
WHERE addons_tags.addon_id IS NULL and
(addons.addontype_id<>3 and addons.addontype_id<>5);

Dictionaries & Lang Packs don't support categories. Many of the others were either "Incomplete Versions" or "Disabled" and I assigned them to the "Other" category so they are not totally blank.

Add-on ID: 4593 is one that I couldn't edit - don't know why. Probably needs a SQL script but since it's disabled, it shouldn't really matter.

I'm going to close this bug but I would request of fligtar that as part of AMO 3.5 that we ensure that if an aborted upload of add-ons maintains either a category of "Other" so that we don't have to deal with this again. Dev CP should enforce this.

Similarly, we shouldn't allow add-on entries on AMO that don't have authors associated with them. The Dev CP should enforce this.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: Add-ons → Administration
QA Contact: add-ons → administration
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.