[Building Sakai] User in sakai_user_id_map but not in sakai_user

[Steve Swinsburg]

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.

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 :)

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


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/20091119/b695a8f8/attachment.html