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

Bug #921994 reported by Patrick Pollet on 2012-01-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

When importing a LEAP2 zip into a 1.5 Mahara site (latest 1.5.0dev from git) and if the new user email is already known, importation proceeds normally but the mahara site then starts to fail in various places (search friends, see groups members) ...

Errors reported in httpd error_log are :

 [Thu Jan 26 10:22:19 2012] [error] [client] [WAR] a9 (lib/errors.php:749) get_record_sql found more than one row. If you meant to retrieve more than one record, use get_records_*, otherwise check your code or database for inconsistencies, referer: http://xxxxxxxxxxxxx/m
[Thu Jan 26 10:22:19 2012] [error] [client] Call stack (most recent first):, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * log_message("get_record_sql found more than one row. If you mea...", 8, true, true)
 at /var/www/html/mahara.git/htdocs/lib/errors.php:109, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * log_warn("get_record_sql found more than one row. If you mea...") at /var/www/html/
mahara.git/htdocs/lib/errors.php:749, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * SQLException->__construct("get_record_sql found more than one row. If you mea...")
at /var/www/html/mahara.git/htdocs/lib/dml.php:339, referer: http:///mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * get_record_sql("SELECT * FROM "usr" WHERE "email" = ? ", array(size 1)) at /var/www/html/mahara.git/htdocs/lib/dml.php:302, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * get_record("usr", "email", "<email address hidden>") at /var/www/html/mahara.git/htdo
cs/local/insa/remote_avatar.php:17, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * local_remote_avatar("<email address hidden>", array(size 2), "http://xxxxxxxxxxxx/mahara/theme/raw/stat...") at /var/www/html/mahara.git/htdocs/lib/user.php:2246, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * remote_avatar("<email address hidden>", array(size 2), "http://xxxxxxxxxxxx/
mahara/theme/raw/stat...") at /var/www/html/mahara.git/htdocs/lib/user.php:2227, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * profile_icon_url(object(stdClass), 40, 40) at /var/www/html/mahara.git/htdocs/lib/d
woo/mahara/plugins/function.profile_icon_url.php:13, referer: http://xxxxxxxxxxxx/mahara/
[Thu Jan 26 10:22:19 2012] [error] [client] * Dwoo_Plugin_profile_icon_url(object(Dwoo_Mahara), object(stdClass), 40, 40) at /wor
k/maharadata/dwoo/compile/insalyon/var/www/html/mahara.git/htdocs/theme/raw/templates/user/user.tpl.d17.php:92, referer: http://xxxxxxxxxxxx/mahara/

It is also impossible to delete that user under site administration since getting that user data fails with the above error...

To return site to 'normal operation' one has to go to table usr and manually edit the new user email to an unique value


Edit : I did not tested it yet, but I do hope that this behaviour does not occur also in importing users from a CSV file ;-)

Patrick Pollet (pp-c) on 2012-01-26
description: updated
description: updated
tags: added: leap2a
removed: leap2 unicity
Changed in mahara:
status: New → Triaged
importance: Undecided → Medium
milestone: none → 1.5.0

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

Patrick Pollet (pp-c) wrote :

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] * 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


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.


Changed in mahara:
milestone: 1.5.0 → none
status: Triaged → Confirmed
Changed in mahara:
milestone: none → 1.6.0
Son Nguyen (ngson2000) on 2012-09-07
Changed in mahara:
assignee: nobody → Son Nguyen (ngson2000)
Changed in mahara:
milestone: 1.6.0 → none
Son Nguyen (ngson2000) on 2013-01-18
Changed in mahara:
assignee: Son Nguyen (ngson2000) → nobody
Son Nguyen (ngson2000) wrote :

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

Aaron Wells (u-aaronw) wrote :

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.


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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers