Synchronizing Group Memberships

Background

In early versions of EVALSYS, calls were made to a group provider whenever information was needed about membership in an eval group. This included getting a list of evals in which a logged-in user has a role (evaluatee or evaluator). It also included getting lists of users with roles in a particular evaluation. Consulting the group provider frequently proved to be expensive (especially in some cases where information needed to be "joined" with information from EVALSYS's internal database tables), so group membership data was added to the persistence layer of EVALSYS so it could be retrieved directly from the database when needed, without frequent queries to the group provider. That required that the database tables containing that group membership data be kept in sync with the information that would be provided by the group provider.

In the 1.3.x branch of EVALSYS (as well as in some tags of the 1.2.x branch?), the group provider was consulted and the group membership data was updated at particular times in the life cycle of an eval and normal functioning of sakai, including:

  • When a new assign-group object was created and saved
  • When certain properties of an assign-group were updated
  • When the "state" of an eval changed (especially from InQueue to Active?)
  • When a server was started up

In the 1.4.x branch of EVALSYS, new admin controls were added to determine circumstances under which the group memberships would be synchronized with an external group provider. The default behavior remained the same as in the 1.3.x branch, but in 1.4.x, admins were given more control over the provider-sync process. The admin could trigger provider syncs in three categories:

  • Based on events such as those mentioned above
  • At a particular time
  • Immediately

The admin pages for EVALSYS in 1.4.x include a link for a special page titled "Synchronize Group Memberships". That page has three tabs corresponding to those three categories:

  • By trigger/event
  • By time and state
  • Quick sync

Synchronize group memberships by trigger/event

The first tab allows admins to schedule syncs at particular times in the life cycle of an eval and normal functioning of sakai, as described above. The default is for the syncs to occur at the same times as in the 1.3.x branch. This tab makes it possible to turn off syncing when those events occur.

This tab also includes a select-element to choose which server in a cluster will handle group-membership synchronization. The choice made there is a global property that affects all sync operations, no matter how they are scheduled. The user must click the "save changes" button to make a change in the existing settings.

Synchronize group memberships by time and state

The second tab enables scheduling of group-membership syncs at particular times (e.g. every Saturday at 5 a.m. or every other day at 1:30 a.m. or today at 3 p.m.).

The default view of this tab includes a list of previously-scheduled syncs with links to delete or revise them. Times are expressed as "cron expressions" (the screenshot below includes a sync every day at 10:12 a.m.). This tab also includes a link to add a new sync.

Clicking on the "add sync" link or the "edit" link for an existing sync displays a form for setting properties when scheduling a sync.

The user would enter a cron expression in the first field of this form. Clicking on the "?" link displays a page describing how to write cron expressions. If the user is editing an existing sync, the cron expression can be revised to change the time(s) at which the sync occurs. The user also determines which evals will be affected by this sync by checking the "states" that will be included. As above, the user can select which server in a cluster will handle all group-membership synchronizations, no matter which tab was used to schedule the sync. The user must click "schedule sync" to create a new sync or revise an existing sync.

Synchronize group memberships by quick sync

The third tab allows a user to schedule a group membership "immediately", which actually means two minutes after the user submits the form in that tab by selecting one or more "states" and clicking on the "synchronize now" button.

As above, the user can select which server in a cluster will handle all group-membership synchronization. Successfully submitting the form results in addition of a sync that can be seen in the "by time and state" tab. The cron expression in this case specifies a time two minutes after the exact second at which the form was submitted. That sync will disappear from the list in the "by time and state" tab shortly after the sync process is completed.