Wednesday, March 26, 2008

Section provisioning, de provisioning, and re provisioning

So I got to work on SAK-11320 again.

( I hope these posts sorta explain my work setting... )

We have users who get a snapshot of Registry Roster data into their sites and then TURN OFF roster synchronization by switching Section Administration to manual. I think they just want to reduce the amount of change they have to deal with.

Here's how the Groups look at the beginning of such a cycle:

Groups -fbdb0 and -e0f9a have Provider Ids allowing Sakai to go out and get folks for those groups.

We switch to Manual Section administration.

The Section Manager strips the Sakai Groupz of ProviderIds, and shuffles the current membership over to the Sakai Group. Everything works nicely.



Later on they turn the Roster Sync feed back on. Think of it as refreshing their Roster.

So in doing this last step the underlaying Section Manager impl creates new Realms. It leaves the old Realms. The new Realms are re-wired with ProviderIds, and new people pour in.Now we have 2 new groups. We also have the previous groups. I call them "orphaned" groups. The two new groups are pulling membership from whatever is at the other end of the ProviderId; that info is being used in Site Info and Section info as a source of rosters.

The "orphaned" groups also have Roster information. It may well be out of date with whatever is coming in now from the Provider.

Who cares?

Unfortunately most of the Section Aware tools stash the Group Id in private storage; often in XML in private storage.

This means that any Section ACLs created in Section aware tools are pointing at whatever Group was active when the ACL was created.

Guess what; the new Groupz are not the ones stashed away are they?

The new Groupz mostly have the same people as the old, stashed away Groupz. However the Stashed away Groupz will have people who may of dropped the Course. The stashed away Groupz will not have people who have added the course.

The Section Info tool shows these new people, and does not show the dropped people. Yet the dropped people still get announcements, still have access to section resources. New people are prohibited from getting resources.

Its a help-ticket fest.

So today I put in a small patch which restores the ProviderId for the once-disconnected Groupz. And we don't generate new Groupz for previously provided Sections.

We still have a problem of new sections lingering; but they remain invisible to all but super users... modulo the effects I describe above.

I don't know if it's 'good' to have ACLs wiht non-existing Groupz. That's for tomorrow. Probably each tool will be different.

No comments: