679193 - profile: bug - duplicate interests

Status: VERIFIED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[Luke Crouch [:groovecoder]]

Might be seeing this now that users are filling in the interests tags?

1. Edit your interests with a popular auto-complete, e.g., javascript
2. Save profile

Interests shows "JAVASCRIPT javascript Javascript"

Comment 1

[Luke Crouch [:groovecoder]]

Just show lowercase tags.

Comment 2

[Les Orchard [:lorchard]]

django-taggit tags are case-sensitive. 

The easiest fix would be to force all tag input to lower-case at the form or model level.

A harder fix would be to subclass some django-taggit model classes to do case-insensitive queries when looking for existing tags. That way, the first tag spelling wins. However, that would not preserve the tag case per-user. (eg. user1 uses JavaScript, user2 uses javascript but sees JavaScript)

Preserving case per-user would be much, much harder and not really worth pursuing, IMO. 

If we really wanted to be picky about case in spelling, we could impose spelling for recommended tags and accept the first user's spelling for all other tags.

Comment 3

[Luke Crouch [:groovecoder]]

I think convert everything to lower-case at the model level is the best answer.

Comment 4

[Les Orchard [:lorchard]]

(In reply to Luke Crouch [:groovecoder] from comment #3)
> I think convert everything to lower-case at the model level is the best
> answer.

model-level is slightly trickier than form-level, too, FWIW. 

In the form, it would probably be a one-liner in the clean method. For the model, you'd need to make a subclass of two taggit manager classes.

Comment 5

[Les Orchard [:lorchard]]

Bumping to 1.2 for triage, since we're at code freeze for 1.1 and these bugs are most likely not going to make it.

Comment 6

[James Bennett [:ubernostrum]]

On further investigation, this one's deep enough that it isn't going to make it for 1.2 (and may need splitting up into multiple bugs for 1.3 or later).

Comment 7

[James Bennett [:ubernostrum]]

OK, so this one is *really* fun. It only manifests on MySQL, and only when MySQL is using a case-insensitive collation (I've got a minimal app/project that can replicate this easily).

Fixing it is going to involve:

1. Changing the way we handle tags to force them to a consistent case on saving (which will avoid ending up with multiple versions of a tag in different cases). This isn't too bad.

2. Figure out a way to unify the existing tags in the DB to that consistent case scheme, and migrate all the existing data without dropping any individual user's tags in the process. This is hard. Or...

3. When we fetch a user's tags, filter them somehow to only get tags in the case scheme we're actually going to use. This is more of a band-aid approach, but could be done a bit more quickly than the real solution in (2).

Comment 8

[James Bennett [:ubernostrum]]

Per Luke, bumping to 1.4; we'll probably go with the band-aid approach there, and then figure out the scheduling to do the permanent fix later one.

Comment 9

[[github robot]]

Commit pushed to https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/fc588ffc4dafd5c76b81383535960616dfdb988d
Bug 679193: Do some case-based filtering of duplicate tags as a band-aid until we solve the real case-sensitivity problem.

Comment 10

[[github robot]]

Commit pushed to https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/fc588ffc4dafd5c76b81383535960616dfdb988d
Bug 679193: Do some case-based filtering of duplicate tags as a band-aid until we solve the real case-sensitivity problem.

Comment 11

[[github robot]]

Commit pushed to https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/85e76874b1fe4bbfb387bc132bf86b9af71da8f3
Bug 679193: Regardless of whether we ever work out a migration for killing the existing dupes, we need this to avoid creating new ones.

Comment 12

[raymond [:retornam] (inactive)]

verified fixed https://developer.mozilla.org/en-US/profiles/groovecoder/