Child pages
  • Roster Synchronization
Skip to end of metadata
Go to start of metadata
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

Title:

Roster Synchronization

Jira Number:

SAK-16693

Related Jira Numbers:

TBD

Component(s):

Matrices, Evaluations, Wizards, Groups, Roster

Author:

Lynn Ward, Indiana University

Date:

July 1, 2009

Demo Status and Date(s):

Status: Pending
Date: Demoed most recently on February 15, 2010


Part 1: Functional Description


Roster Synchronization (1)

Summary (1)

Roster synchronization is a new option under "Manage Site Associations" in the Matrices tool that functions as a toggle.  When another Sakai course or project site is associated with the current site with roster synching turned on, the students (or members) of the associated site are automatically added to the current portfolio site and a new editable group with the members of the associated site is created.  As members are added to or deleted from the associated site, the roster and associated group membership in the portfolio site is dynamically updated.  The feature reduces the administrative overhead of manually updating he portfolio site roster when assignment linking is used in a large number of course sites. 

Rationale (1)

At IU, the rosters for all course sites are autopopulated from SIS data, but portfolio rosters must be maintained by hand.  Many of our portfolio projects involve collecting examples of student work from multiple courses over multiple semester.   To maintain the rosters for these projects, the coordinator must import the roster for each course participating in the project at the beginning of the semester, and add individual students that enroll in the course following the import.  This is a labor intensive process and late enrollees are inevitably locked out of the portfolio site until the site coordinator is notified.  This feature eliminates the need  to manually populate and maintain the portfolio site participant roster in cases where the roster is made up largely of course sections. 

Origin (1)

The need for this enhancement arose at Indiana University in connection with two early portfolio projects, the English Capstone portfolio and the Transition to Teaching Portfolio.  In both projects, students enrolled in specific courses are required to complete a portfolio matrix or wizard published in a portfolio site.  The same site and scaffolding is used each semester to facilitate longitudinal reporting.  In both cases, after one semester of maintaining the roster manualy, the site coordinator requested an automated approach.  The need has become even more pressing as we've begun to mount large-scale programmatic assessment projects in which multiple course sites are associated with the Matrices tool each semester.

User Stories (1)

The User Stories should paint a picture of what it is like for a user to make use of the enhancement. The actors should be based on real users with definable tasks and goals. Include as many stories as necessary to demonstrate how the enhancement would be used by different types of users.

Actors and Stakeholders

  • Portfolio site coordinator - this feature is intended to benefit the site coordinator by automating a process that is otherwise hadnled manually.  Instead of manually importing rosters from associated sites, the coordinator  enables roster syncing
  • Instructor - without this feature, instructors teaching associated courses must notify the portfolio site coordinator when students add or drop the class after the initial roster import.
  • student/participants - the impact on students is negligible, since they are not typically aware of how they are added to or removed from portfolio sites.

Coordinator Associates Sites with Roster Syncing Enabled

  1. Coordinator establishes a portfolio site for programmatic assessment
  2. Coordinator creates and publishes a matrix that represents the department's essential learning goals or outcomes
  3. Coordinator associates multiple courses taught by the department with the Matrices tool and syncs the rosters.
  4. Students in each associated course sites are added to the portfolio site and a separate group is created for each associated site.
  5. As students add or drop one of the associated, the portfolio site roster and  group membership is dynamically updated.

Coordinator Disables Roster Syncing for a Course

  1. Coordinator learns that the enrollment in one or more courses taught by the department is primarily non-majors who should not be tracked in the matrix.  Only enrolled students who are majors should be added to the portfolio site
  2. Coordinator turns roster syncing off for the designated courses.
  3. The students in the associated courses for which syncing was disabled are removed from the portfolio site roster and group unless they are in another associated course.
  4. The coordinator manually adds the majors from the courses in which syncing was disabled to the portfolio site and corresponding course group.
  5. The course sites in which syncing was disabled continue to be associated with the portfolio site, so the instructor can continue to link assignments to matrix cells in the portfolio site.
  6. When students submit linked assignments, those that were manually added to the portfolio site will see their linked assignments in the matrix. 

Functional Details (may be added after community demo) (1)

See OSP Roster Automation Design Document.

Interaction and Implications (1)

At the current time, roster synching only affects users in the following roles:

  • Course sites:  student
  • Project sites:  student, member
  • Portfolio sites: participants

 When roster syncing is enabled, users in the above roles are added to the portfolio site as "participants"

Roster syncing affects other Sakai tools in the following ways:

  • Site Setup - users added to the portfolio site appear in the roster as participants. 
  • Site Setup > Manage Groups:  a separate group is automatically created for each associated site with roster syncing enabled.  The group can be manually edited.  If roster syncing is turned off and the only group members were those in the associated site, the group is deleted automatically.  If the group contains members that are not in the associated course, the group remain intact.
  • Roster - participants provided via roster syncing are listed in the site roster and identified as members of the groups created when the site was associated.

Diagrams and Mockups (3)

See OSP Roster Automation Design Document.

Community Acceptance (4)

This feature was described in two presentations at the 2009 Sakai Conference in Boston.  In addition...



Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.


Specification Template (5)

Behavior


See OSP Roster Automation Design Document.

Quality Metrics

Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.

Assumptions

Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.

Outstanding Issues

The Outstanding Issues section is a placeholder for the evolution of this specific feature. It should mention any explicit design or implementation decisions that are pending. There must be no outstanding decisions as of the confirmation of the feature as a requirement.

Configuration Information

For those folks interested in customizing the configuration, here are some examples and a few options for implementing those customizations.
The default configuration might look something like this:

<!--
Configuration object which can safely be overridden by a deployment's
sakai-configuration.xml file.
-->
<util:map id="org.sakaiproject.coursemanagement.GroupProviderConfiguration">
	<entry key="siteRoleResolutionOrder">
		<list>
			<value>Instructor</value>
			<value>Teaching Assistant</value>
			<value>Student</value>
		</list>
	</entry>
	<entry key="officialInstructorToSiteRole" value="Instructor"/>
	<entry key="enrollmentStatusToSiteRole">
		<map>
			<entry key="enrolled" value="Student"/>
			<entry key="wait" value="Student"/>
		</map>
	</entry>
	<entry key="sectionRoleToSiteRole">
		<map>
			<entry key="I" value="Instructor"/>
			<entry key="GSI" value="Teaching Assistant"/>
			<entry key="S" value="Student"/>
		</map>
	</entry>
	<entry key="courseOfferingRoleToSiteRole">
		<map>
			<entry key="CourseAdmin" value="Instructor"/>
			<entry key="I" value="Instructor"/>
		</map>
	</entry>
	<entry key="courseSetRoleToSiteRole">
		<map>
			<entry key="DeptAdmin" value="Instructor"/>
		</map>
	</entry>
</util:map>

At IU, our config looks like this:

<util:map id="org.sakaiproject.coursemanagement.GroupProviderConfiguration">
	<entry key="siteRoleResolutionOrder">
		<list>
			<value>instructor</value>
			<value>teaching assistant</value>
			<value>student</value>
			<value>participant</value>
		</list>
	</entry>
	<entry key="officialInstructorToSiteRole" value="instructor"/>
	<entry key="enrollmentStatusToSiteRole">
		<map>
		</map>
	</entry>
	<entry key="sectionRoleToSiteRole">
		<map>
			<entry key="student" value="participant"/>
			<entry key="access" value="participant"/>
			<entry key="participant" value="participant"/>
			<entry key="member" value="participant"/>
		</map>
	</entry>
	<entry key="courseOfferingRoleToSiteRole">
		<map>
		</map>
	</entry>
	<entry key="courseSetRoleToSiteRole">
		<map>
		</map>
	</entry>
</util:map>

We're not using any of the "real" Course Management stuff, so if you are, YMMV here!  For our implementation, we only used the sectionRoleToSiteRole portion and had all of the "access" level roles map over to the participant role (of a portfolio site).  Our roles are customized here, so yours again may be different.  There's not much to it, really.

As far as where to do the configuration, you can either change the file directly (/providers/component/src/webapp/WEB-INF/components.xml), or if you have a sakai-configuration.xml file in your tomcat/sakai folder, you can override it there.

  • No labels

3 Comments

  1. Comments from OSP t-con Feb  15, 2010

    • Roster association currently associates/copies only students (and possibly duplicated as "CIG Participant" role). We'd prefer having all users associated/copied, and have the role selected by the (admin) user during the roster association process.
    • What happens to portfolio users if course site is hidden?
    • What happens to portfolio user if course user is made inactive in course site?
    • Perhaps roster association should instead by a "snapshot" copy of users from one site to the other? This would solve above two questions.
    • Perhaps this entire functionality should be merged with the Site Info tool's "Import from Site" -> "I would like to merge my user(s)"?
    1. According to Chris, this is all handled via an XML config file.  The settings apply server wide, which means the same role mappings will be used whenever syncing is turned on.  But each institution can control which roles are synced and how those users are mapped to roles in the ePortfolio site.  In other words, even though IU's local configuration only moves users in  "access" - type roles,  it is possible to move and sync users in all roles and to specify the role that should be applied in the target site.  

      Chris will be providing documentation on how to customize the mappings, but the good news is that it doesn't require any changes to the application code.

      Developing a UI for selecting and mapping the roles on a per site basis will require a lot of additional design and development.  Given all of the other projects on their plate,  it's unlikely our development team will be able to get this work done for 2.8.  So a question to consider during an upcoming call is whether the current configuration methods and options are flexible enough to meet the needs of other institutions.  

      Regarding how roster syncing and assignment linking is affected by making students inactive in the associated site or hiding (unpublishing) the associated site, I did some brief testing with the following results:

      • If a synced user is made inactive in a course site that has been associated and synched with the portfolio site:* The user remains in the portfolio site with an "active" status.
      • The user's submissions to the matrix made directly or via assignment linking are still visible.* If an associated site with roster syncing is hidden (unpublished)* Synced users remain in the portfolio site with an "active" status.
      • The user's submissions made via assignment linking are visible only to those who have permission to access the unpublished site.  Work added to the matrix directly by the synced user is unaffected.
  2. Comments from March 8th t-con

    • add as optional feature (ideally as a optional site property) prior to merging to trunk