Check for existing email
Description
Attachments
is depended on by
Activity

Matthew Jones May 10, 2015 at 5:29 PM
It looks this was incorporated by

Alexandre Ballesté Crevillén November 7, 2014 at 1:02 AM
SAK-26158-trunk.patch included in this jira is not valid anymore. Seel to get the patch remake.
Stephen Marquard October 5, 2014 at 12:07 PM
From our production database:
select EMAIL_LC, COUNT(EMAIL_LC) FROM SAKAI_USER GROUP BY EMAIL_LC HAVING COUNT(EMAIL_LC)>1;
689 rows. When we set up Sakai at on our campus in 2005, it was a conscious design decision that we would not require or enforce email address uniqueness.

Matthew Jones October 3, 2014 at 6:40 PM
If you look at some original design, issues like were specifically addressed to allow users to have the same email address on multiple accounts, so someone is for sure using this.

Matthew Jones October 3, 2014 at 2:07 PM
This is not going to get committed without the option to disable it. It changes the existing behavior of addUser which while may be undesired for some instances can be useful for testing and may be what some institutions want to preserve.
I'd do it right here in this code and make the property something like "user.duplicate.email=true/false".
I'd also like if this method that checked for duplication was separate so we could call it from the api without calling addUser. That way it could be used to clean up old emails, or possibly even be used to check in the UI prior to the user being created.
So maybe like
boolean isEmailDuplicate(String email) . . . Relaly if all this is checking is if findUsersByEmail is > 1 right? Is that for loop checking against the id's really even needed?
Opening up a kernel ticket as SAK-26158 has a few kernel changes.