Case-sensitive username matching

[adehnert]

When matching usernames (eg, on the people management page) we should do a case-sensitive match. At the moment, people can add "Anandk" as having office access, which breaks space/dump/office-access.csv (see ​https://diswww.mit.edu/menelaus/asa-db/4203, for example).

[adehnert]

I've verified that this is doable from the usual "update people" interface.

[adehnert]

Apparently under sqlite this is done case-sensitive and on mysql it's case-insensitive...

[adehnert]

I think the proper solution involves the South equivalent of "ALTER TABLE groups_athenamoiraaccount MODIFY username varchar(8) COLLATE utf8_bin;"; I did this on db2.0 and it started giving me errors when editing ​https://asa.scripts.mit.edu/db2.0/groups/1923/edit/people. We probably also want to lower-case all the existing username fields.

[adehnert]

Fields that need to be lowercased:

• groups_groupstartup: president_kerberos, treasurer_kerberos (four groups involved: one has N/A for the fields, one has both wrong, and one each have only president/treasurer wrong)
• groups_groupnote should not get updated: author includes some @SYSTEM accounts
• groups_officeholder: person (190 entries)
• groups_athenamoiraaccount should not get updated -- it's autoloaded, presumably correctly

[adehnert]

Useful references:

• MySQL docs: ​https://dev.mysql.com/doc/refman/5.0/en/charset-mysql.html
• Various commands to view/change collations: ​http://stackoverflow.com/a/6052541/1797496

[adehnert]

Apparently comparing between non-matching collations works poorly, so we're going to need to change more than just the one column's collation. (I'm guessing we want to change the default collation for the DB, long term? *sigh* I guess sqlite is already case-sensitive, so it's not like case-sensitivity is a disaster.)

Also, it turns out the space dump cares about other issues -- trailing spaces in usernames. I have no idea how *those* happened, but there were about 42 in the prod DB (which I just fixed).

[adehnert]

Django doesn't have an API for setting this, so we're probably going to need to include raw SQL in a migration, I guess? See ​https://docs.djangoproject.com/en/1.8/ref/databases/#collation-settings.