[Building Sakai] User in sakai_user_id_map but not in sakai_user

[Kenwrick Chan]

Hi Steve,
[more]
On Nov 18, 2009, at 1:28 PM, Steve Swinsburg wrote:

> Hi Kenwrick,
> 
> I'm a little confused about whether you want/need all users to have records in SAKAI_USER or not. If you authenticate via LDAP, you can pull all of their info from LDAP (name and email) and they never need a SAKAI_USER record. So it wouldn't matter when they login because there is nothing to get out of sync.
> 
We just use ldap for our authentication portion but perhaps we should revisit how we've set that up.  When we search for a user via Admin's User, or when a user tries to modify their account via Preferences, or adding a user to a site via "Add user" in site info .. all don't work properly without a sakai_user record with our set up.

> Are you saying that your external system creates records in SAKAI_USER for each user, even LDAP ones, but people are logging in before this happens for their particular account so it gets out of sync? If so, I understand :)
> 
Yes.  The external system also adds unique info into the sakai_user_property  table which allows us to associate course enrollments for the user.

> But, is there a need for having their account in SAKAI_USER at all, or can you just use LDAP for the details. If you really do need the SAKAI_USER record, you could backfill SAKAI_USER from SAKAI_USER_ID_MAP. You may be able to script this via Quartz and recreate the User based on the USER_ID and EID you already have, since you can specify the USER_ID when creating a User. Then do an LDAP lookup to get the rest of the details. Not sure if this will bail though, since there is already a record in the SAKAI_USER_ID_MAP. Some simple SQL will around that, though I don't normally recommend doing direct SQL on the DB itself
> 
That's what I tried to do, backfill sakai_user based on the user_id that's in sakai_user_id_map but it doesn't work  e.g. when we search for a user via Admin's User, or when a user tries to modify their account via Preferences, or adding a user to a site via "Add user" in site info .. all don't work properly with an account backfilled in this way.  So I was wondering if there was another table that also needed to be updated.

Thanks,
Kenwrick

> 
> cheers,
> Steve
> 
> 
> 
> On Thu, Nov 19, 2009 at 10:14 AM, Kenwrick Chan <kchan at hawaii.edu> wrote:
> Thanks Steve,
> [more]
> On Nov 18, 2009, at 12:57 PM, Steve Swinsburg wrote:
> 
>> If you are using an external provider for instance the JLDAP provider, that is expected behaviour. User's don't have internal accounts so they won't have a record in SAKAI_USER. They should have a mapping in SAKAI_USER_ID_MAP though which links their EID (jsmith26) to their USER_ID (the UUID)
>> 
> Yes, this is the case.  When a user logs in they are authenticated against our ldap.  If they are successful and don't have a local account (in sakai_user) a record gets created for them in sakai_user_id_map (user_id, eid). 
> 
> Generally speaking though our users are created via another process driven by our student information system.    So an odd state for a user's account occurs when a user logs in before the event to generate the user by the SIS is acted upon.  Since this user account with only a sakai_user_id_map exists there is no way to update the user's info and say populate it with courses (since no sakai_user, sakai_user_property record exists for the user).    
> 
>> If you delete their records in SAKAI_USER_ID_MAP they will be given a different UUID when they next login. This will break anything linked to their old ID and is probably bad.
>> 
> 
> So this becomes the process for our account clean up.  Delete the sakai_user_id_map record then generate a new account.  It doesn't happen often, but it does happen especially during peak registration times.
> 
> What I was hoping for was a method to update those account that exist in sakai_user_id_map into full account that are in sakai_user and sakai_user_id_map.
> 
> -kenwrick
> 
>> However, if your provider is setup to also create accounts in Sakai, then something is amiss.
>> 
>> cheers,
>> Steve
>> 
>> On Thu, Nov 19, 2009 at 6:32 AM, Kenwrick Chan <kchan at hawaii.edu> wrote:
>> Folks,
>> Due to the way authentication provider is set up we occasionally get users who appear in sakai_user_id_map and don't have a record in sakai_user.    We've been deleting these and rebuilding them correctly, but I was wonder how other campuses are dealing with it.  Is there a clean way to re-build these accounts?
>> 
>> Thanks,
>> Kenwrick
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091118/f8080621/attachment.html