LEAP2 import does not check if the new user email is already used in Mahara

Hi Patrick,

Unfortunately uniqueness of email addresses is not enforced at the db level yet. We may look at fixing that in future, but first I think we'd need to do a bit of work around how to upgrade old databases. In the meantime you should just avoid relying on uniqueness in your custom code.

If you find any core code relying on uniqueness of emails (you mentioned search friends, and see groups members), let us know in another bug report, and we'll fix it for 1.5.

See also https://bugs.launchpad.net/mahara/+bug/903494, https://bugs.launchpad.net/mahara/+bug/907903

Hi Francois,

> In the meantime you should just avoid relying on uniqueness in your custom code

Yes I just noticed that all these errors were triggered in my custom code to fetch user's avatar from our local gravatar server
that can use either email or student number... My fault ;-)

[Thu Jan 26 10:22:19 2012] [error] [client 134.214.152.108] * get_record("usr", "email", "<email address hidden>") at /var/www/html/mahara.git/htdocs/local/insa/remote_avatar.php:17, referer: http://xxxxxxxxxxxx/mahara/

I fixed it.

Nevertheless I noticed that there is a language string 'emailalreadytaken' that is used in various places as follow :

[root@vm107-04 mahara]# grep -Rin emailalreadytaken *
admin/users/add.php:273: $form->set_error('email', get_string('emailalreadytaken', 'auth.internal'));
artefact/internal/lang/en.utf8/artefact.internal.php:110:$string['unvalidatedemailalreadytaken'] = 'The e-mail address you are trying to validate is already taken';
artefact/internal/index.php:245: $form->set_error('email', get_string('unvalidatedemailalreadytaken', 'artefact.internal'));
auth/internal/lang/en.utf8/auth.internal.php:35:$string['emailalreadytaken'] = 'This e-mail address has already registered here';
local/ldap/cli/mahara_sync_users.php:366: $cli->cli_print(get_string('emailalreadytaken', 'auth.internal') .' '. $ldapusername . ' '.$ldapdetails->email);
maharadata/langpacks/fr.utf8/artefact/internal/lang/fr.utf8/artefact.internal.php:78:$string['unvalidatedemailalreadytaken'] = 'L\'adresse que vous essayez de valider est déjà utilisée';
maharadata/langpacks/fr.utf8/auth/internal/lang/fr.utf8/auth.internal.php:7:$string['emailalreadytaken'] = 'Cette adresse de courriel est déjà enregistrée ici';
register.php:387: $form->set_error('email', get_string('emailalreadytaken', 'auth.internal'));

So there are some provisions, but not everywhere for this uniqueness , at least when an user is manully added to Mahara , but apparently not when he is 'imported' from CSV of LEAP2A

Cheers

Hi Patrick,

You're right, sometimes the application does try to stop duplicate emails, but doing that with Leap2a imports would require bigger changes, so I'm going to remove the 1.5 milestone from this bug.

It's annoying because the current method is to create the user, then subsequently parse the Leap2a file and fill in all the user's profile fields - it's a bit nasty having to throw a duplicate email error at that stage, and then delete the newly created user afterwards. This approach probably wouldn't play nicely with the bulk Leap2a imports anyway.

It'd be easier to require the admin to supply an email along with the Leap2a file in the same way that they have to supply a username, but that requires a couple of UI changes, and I'm not sure it's worth it until we've worked out how we're going to remove duplicate emails from existing sites.

R.

I think an interactive UI importing for a bulk of users needs to be implemented. This will help admins to remove duplicate email addresses.

Hi Son,

Do you mean an interactive UI for bulk-importing LEAP2A files? Because you can already bulk-import users using the "add users by CSV" page.

Cheers,
Aaron

The problem is not the manual creation of users or by CSV but when a Leap2A file is imported or an external auth is used. When an admin uploads a Leap2A file, the DB doesn't check if the email address already exists in the system. Nor are email addresses checked when SAML or MNet are connected.

An admin interface alone would not solve the problem because an admin is not involved when a user connects via SAML forgetting that thy already have an account just with a different auth method.