Child pages
  • Group Provider Requirements
Skip to end of metadata
Go to start of metadata

As I work on the CM group provider, I've been finding that either a) the integration behavior has yet to be fully specified or b) I don't know where the specs are (smile)

In order to get some clarity, I've put together a scenario to explore who would / would not be a member of a site, based on their memberships in CM. In the image below, "Sec" means section, "CO" means Course Offering, "CC" means Canonical Course, and "CS" means Course Set. The different shapes and colors are just there to distinguish between the different kinds of objects. They have no meaning beyond that.

In this scenario, "Sec1" is the only section mapped to our site, "Site 1". The table on the right lists different kinds of associations that could exist between a user and one of these CM objects along with a description of the user's resulting role in "Site 1".

User

CM Membership

Site 1 membership

User #1

Enrolled in the enrollment set attached to "Sec1"

Site member with the configured "enrollment" role (usually "Student")

User #2

Official instructor in the enrollment set attached to "Sec1"

Site member with the configured "official instructor" role (usually "Instructor")

User #3

Member of "Sec1"

Site member with the mapped Sakai role (converted from the CM membership role)

User #4

Enrolled in the enrollment set attached to "Sec4"

Not a site member. Sections must be explicitly mapped, otherwise, they do not feed into the site membership list.

User #5

Official instructor in the enrollment set attached to "Sec4"

Not a site member. Sections must be explicitly mapped, otherwise, they do not feed into the site membership list.

User #6

Member of "Sec2"

Not a site member. Sections must be explicitly mapped, otherwise, they do not feed into the site membership list.

User #7

Member of "Sec5"

Not a site member. Sections must be explicitly mapped, otherwise, they do not feed into the site membership list, regardless of equivalencies / cross listings.

User #8

Member of "CO1"

Site member with the mapped Sakai role (converted from the CM membership role)

User #9

Member of "CO2"

Site member with the mapped Sakai role (converted from the CM membership role)

User #10

Member of "CO3"

Not a site member. Canonical course equivalents (called cross listing in the diagram) do not impact memberships. Only course offering equivalencies are considered when determining site memberships. Is this the correct behavior?

User #11

Member of "CS1"

Site member with the mapped Sakai role (converted from the CM membership role)

User #12

Member of "CS2"

Site member with the mapped Sakai role (converted from the CM membership role)

User #13

Member of "CS3"

Site member with the mapped Sakai role (converted from the CM membership role)

User #14

Member of "CS4"

Not a site member. The Canonical Course equivalency does not apply. Is this the correct behavior?

  • No labels

3 Comments

  1. For good or for bad, I've been away from the project long enough that I'm looking at this with fairly fresh eyes, and it seems counter-intuitive that a site which has been explicitly mapped to members of Sec1 should automatically get members who are not in Sec1. Could you spell out the typical use cases of someone who is a member (and, I presume, ONLY a member?) of "CO1", "CO2", "CC1", "CC2", "CS1", "CS2"? Is the idea that these are user who have roles which implicitly inherit access rights down the tree, such as "Administrators" and "Instructors"?

    If so, is there any way to be explicit about their difference from roles like "Students" and "Section Leaders"? Here's one scenario: Let's say you have a situation where a student is enrolled in a Course Offering but may have to wait to get assigned to a particular discussion section, or may not be required to be in a project section. Does that mean the student shows up in the discussion section's site and project section's site? That doesn't seem right.

    1. Is the idea that these are user who have roles which implicitly inherit access rights down the tree, such as "Administrators" and "Instructors"?

      Yes

      If so, is there any way to be explicit about their difference from roles like "Students" and "Section Leaders"?

      Yes. The current implementation uses a single map to convert between CM roles and Sakai roles. We could, and probably should, refactor the conversions into the individual role resolvers so that a "student" role at the course offering level might map to nothing, and so wouldn't be added to the site, while a "section leader" role at the course offering level would be added with a "TA" role to all sections under the course offering, for instance. All of this would continue to be configurable in components.xml so institutions can easily modify the role resolving behavior at each level of the CM hierarchy.