Grouper Developers Forum

[Peter DiCamillo <>]

In the previous mail I was describing the part of what we do for courses 
that is relevant to ACLs.  The full set of groups for a course looks 
like this:

COURSE:dept:number:term:section:

All
  Administrator
    Instructor
      member SIS Instructor group
    Manager
    TeachingAssistant
      member SIS TeachingAssistant group
  Contributor
    ContentDeveloper
    Mentor
  Learner
    Auditor
      member SIS Auditor group
    Student
      member SIS Student group
    Vagabond

-----

SIS:dept:number:term:section:
  Instructor
  Teaching Assistant
  Auditor
  Student

where I've added the SIS groups.  SIS stands for Student Information 
System, and is a historical name.  The SIS groups are provisioned using 
a feed from Banner, and are not otherwise modified (and have no ACLs.) 
They are the means for including the official registrar's course data.

The purpose for the complexity of the course groups is to allow for the 
full set of IMS roles, as well as local roles we require, such as 
vagabond.  IMS roles are listed at 
http://www.imsglobal.org/enterprise/eninfo03.html at item 4.2.3.1.  In 
addition, the COURSE groups allow us to add additional people to the 
data from Banner.  Here are some typical local use cases:

* The roles not listed under SIS are not supported by Banner, and can 
only be entered in the COURSE groups.

* There are Banner restrictions on who can be entered as a TA, and other
TAs not included in Banner need to be added.

* Someone may have some kind of instructor role in a course, but not be
an official instructor in Banner.

* The manager role may be used when departmental support staff is 
assisting a professor with a course.

In practice, we could manage with less complexity.  For example, the 
Contributor roles are seldom used.  But it seemed best to allow for 
everything we might need from the start, since it would be difficult to 
change the structure later.

Peter

Jim Fox wrote:
> Just curious, do you have use for this complexity?  We get by pretty well 
> with one group per course, with members (students plus instructors) and 
> instructors (just the instructors).  This is in the grouper registry, and 
> translates directly to ldap.  All our course information come from 
> institutional data, so we have no admins of any sort for courses.
>
> Jim
>
> On Sep 28, 2010, at 7:57 PM, Peter DiCamillo wrote:
>
> > I noticed that Tom put this on the agenda for Wednesday's call, so I 
> > want to describe in more detail what we would like to able to do.  It's 
> > more complex then just setting an ACL for all the groups under a stem.
> >
> > The names we have for course groups are, for example, 
> > COURSE:CSCI:1230:2010-Fall:S01:id, and for each of those we have 12 
> > groups in a tree structure of indirect memberships like this:
> >
> > id:
> >
> > All
> >   Administrator
> >     Instructor
> >     Manager
> >     TeachingAssistant
> >   Contributor
> >     ContentDeveloper
> >     Mentor
> >   Learner
> >     Auditor
> >     Student
> >     Vagabond
> >
> > The leaf groups (Instructor, Manager, etc) with people as members are 
> > the ones which may need to be modified by staff.  The other groups 
> > should not be modified, but need an ACL to allow staff to view the 
> > membership.  So for a rules-based solution, we would want to be able to 
> > grant a privilege to all the groups under the COURSE stem which have 
> > certain IDs, and specify a different privilege for groups under the 
> > COURSE stem with other IDs.  I'm not very concerned about the time 
> > needed to delete 475K group membership if I know we'll be able to 
> > upgrade to a rules-based solution that meets our needs.
> >
> > Peter