[Building Sakai] User in sakai_user_id_map but not in sakai_user
Kenwrick Chan
kchan at hawaii.edu
Wed Nov 18 16:19:11 PST 2009
Steve,
I "think" I got backfilling to work. Think it was my cacheCleanerMinutes at org.sakaiproject.user.api.UserDirectoryService= setting adding to the confusion.
Thanks!
-Kenwrick
On Nov 18, 2009, at 1:41 PM, Kenwrick Chan wrote:
> 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/34ee63ca/attachment.html
More information about the sakai-dev
mailing list