Wednesday, December 19, 2007


I don't think that refreshUser, as it is in the stock Sakai, needs to be called as often as it is.

To speed up login this past Fall we've taken a few steps. The first was to constrain Realm / Role resolution to the current Term. That was nice, as the Role Resolvers didn't have to crawl across all possible Term/Section combinations for Instructors. But then we pushed it further and removed all calls to refreshUser from the login sequence. ZIP. Due to the lack of Role checking of any sort our users got in quickly and our database as not being reduced to a heap of smoldering salmon. The user Site membership was pulled from SAKAI_SITE_USER w/out an issue, and when the user navigated to the site their roles were pulled. (Sakai recalculates this stuff all the time.)

At the end of the Term we've found that a set of users were loosing their site membership. It was those users who had had Support perform a "Become User" operation in resolving various issues. The Become User operation was using the Term aware changes we had added and stripping the User from all the past term Sites for which they were provided. Since the Term dates ( see the jira about 'Term effective dates' ) had passed, officially, the Sites for that Term were being stripped of those users who had Support issues warranting a Become User session.

Pretty darn confusing.

Especially as each CM Sync job, to work around other bugs in Sakai, was doing a Site Save and a toggle of Section Administration settings to keep the Realm info up to date. These pushed the users back INTO the sites they were in. Depending on when the user logged in they may or may not of had access to their previous quarters Sites.

Here is my log from the internal Sakai confluence site:


Working steps. done in my dev instance, against my dev oracle database.

  1. bring up Stan2.4.x_D
  2. login in as self
  3. review test site Su07-xoxo-001-01
  4. review Su07 term - it's not active. but my instructor membership in the site shows the site on my pulldown (the tab area is full)

this gives me a list of folks. I am the instructor and cwrks223 is a student.

I move to another computer and log in as admin/admin.

  1. login as admin/admin
  2. test cwrks223 account via SU 'LDAP Peek' to see if account looks OK. it does.
  3. SU to cwrks223

At this point the Site is not listed.
I move to the first computer

  1. on first computer I log out of Caseyd1 session
  2. log in as cwrks223
  3. review tabls *No Su07-XOXO-002

what's wrong with this? I didn't log in as cwrks223 FIRST. doh. notice that there was no syncing going on at this point.

  1. on second computer I log in as caseyd1
  2. I review membership in Su07-XOXO-001-01. cwrks223 is missing.
  3. using SQL Developer I examine database tables:
    1. user is still in CM data
    2. user is not in SAKAI_SITE_USER for this site
    3. user is not in REALMS for this site
select * from sakai_realm
where realm_key in
(select realm_key from sakai_realm_rl_gr where user_id = 'cwrks223')

-- works for this user in my DB due to sakai_id == EID for user

This confirms that SU strips sakai site associates for out of term sites.

  1. on the second computer I run Site Sync for Su07-X0X0
  2. on the first computer ( cwrks223 account ) I nav to a tab
  3. on the first computer my site membership returns

This confirms that Sync Site, when it refreshes the Site against the updated CM data, restores the user to the various Sakai side records.

  1. in SQL developer I repeat the above query
    1. the user is now in the top level Realm for the site
    2. the user is now in the proper section Realm for the site.
  2. on the first computer I navigate to the Membership tool. cwrks223 membership now shows the proper list.

to test "update participants' refreshing

  1. on second computer SU to cwrks223
  2. on second computer cwrks223 confirm that I don't see the Su07-XOXO site
  3. on first computer cwrks223 tab-nav to a site, and lose Su07-XOXO membership
  4. on second computer logout cwrks223 and login caseyd1
  5. on second computer caseyd1 tab-nav to Su07-XOXO and Update Participants.
  6. on second computer caseyd1 see cwrks223 return to membership list.
  7. on first computer cwrks223 tab-navs to a site, and regains Su07-XoXO membership

this confirms that an admin or instructor using Update Participants for a site restores sakak-lost members by refreshing against unchanged CM data.

Ok, so that's the testing part.

Dialing in on the problem leaves us with BecomeUser being the starting point for investigation. Our Term-based optimizations are being used by the Sakai Kernel to remove prior terms for those users who have been "Become Usered" by our Support team. well that sucks.

A patch is to remove the refreshUser call from Become User. The privs are actually calculated when the user navs to the Site in question. think 'lazy loading.' :)

This is the second place where we've removed the call. The first is in the login sequence. I think that Sakai is resolving User membership rights when the user navs to the site just fine.


I think that the 2.1 era addition of the SAKAI_SITE_USER table allows us to drop a lot of the confusing Realm scrubbing. It just wasn't reviewed at the time.

No comments: