It is not possible to log in into a slave domain when there are two usernames that differ only by the characters case

Do you know where in the code this problem arises?

There are some explicit calls to "lower" in some of the queries. I think that makes sense on the e-mails but not on the usernames.

IMO, the module should have that settings, if it is thought to work also on other Drupal sites.

Would it be possible just to clarify the difference between d.o. and other Drupal sites?

If there is a difference, I'd have thought that Bakery should handle the standard Drupal case, with any customisation in the drupalorg module?

Thanks for the explanation.

I'm very keen for Bakery to be a generic module as well as for d.o. (i.e. for my sites), so keen to make sure that any changes do not impact negatively on generic installations.

Based on what you've said, i'd be very keen for the settings as you said in #3 - defaulting to the current behaviour (i.e. the drupal norm).

Here is a patch that will apply to D6 installs.

It takes the removal of the LOWER() functions as in kiamlaluno's patch in #3, but only applies the change based on an admin setting, which defaults to the current (non-patched) behaviour.

While this code is safe on its own, it feels weird to me and is not typical Drupal style.

        $condition = variable_get('bakery_username_case', FALSE) ? "name = '%s'" : "LOWER(name) = LOWER('%s')";
        if (db_result(db_query("SELECT COUNT(*) FROM {users} WHERE uid != %d AND " . $condition, $user->uid, $cookie['name'])) > 0) {

I think it would be better

if (variable_get('bakery_username_case', FALSE)) {
if (db_result(db_query("SELECT COUNT(*) FROM {users} WHERE uid != %d AND LOWER(name) = LOWER('%s')", $user->uid, $cookie['name'])) > 0) {

...etc....

No problem. Revised patch attached.

Attached is the patch for D7 (HEAD). #10 is for D6.

This also removes a line of code that has appeared somewhere in the port.

Is this patch live on groups.drupal.org yet? I ask, because I and others are having problems logging-into that site, which sound like they could be caused by this issue. See http://drupal.org/node/897122.

I'm just pinging for an update on this. I've noticed this behavior happening on a.d.o and the Chicago site.

subscribe

The patch looks sound but I'm having a hard time testing this.

In case it was your stopping point, the users.name for drupal.org has the collation utf8_bin.

I got that form show full columns from users;

Thanks, it's more an issue with recreating the problem so I test if the patch fixes it.

@greggles, can I test this on groups' scratch?

For Drupal.org, the real issue is even having usernames which only differ by case used, #1034852: Clean up accounts with case-insensitive duplicate names.

Test to see if this is happening in the latest version.