Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Class Rosters for Grouper

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Class Rosters for Grouper

Chronological Thread 
  • From: Alan Crosswell <>
  • To: Julio Polo <>
  • Cc: Jeff McCullough <>, Jim Fox <>, Bill Thompson <>, Grouper Users <>
  • Subject: Re: [grouper-users] Class Rosters for Grouper
  • Date: Fri, 10 Jul 2020 15:02:49 -0400

At CU, course membership is a Grouper reference group that is reflected in our LDAP as one of many multi-value attributes attached to each person. The group names look like 

CUcourse_<course_id>_<section>_<year>_<term> so they are globally unique but we only retain the data in LDAP when it is relevant (+- a few semesters)

On Fri, Jul 10, 2020 at 2:49 PM Julio Polo <> wrote:
We don't push the information to LDAP, but the information is indirectly reflected in LDAP as application-specific groups.

Applications can create Grouper groups that use any reference groups (approval is required for using any reference group, including access via API).  Our group UI has a setting to toggle whether the group is exposed in LDAP (and therefore also available through CAS and Shib)


On Fri, Jul 10, 2020 at 7:01 AM Jeff McCullough <> wrote:
The other part of this question to me is how those groups are provisioned elsewhere, say LDAP or AD given the membership is ferpa protected. Are you pushing the groups to LDAP/AD or requiring Grouper API access?


On Jul 8, 2020, at 11:06 AM, Jim Fox <> wrote:

University of Washington’s course naming plan dates from about 15 years ago.  It predates our use of Grouper. Basically,


 (QQQ = spr|sum|aut|win)

The only real issue I have with it is the lack of hierarchy,

Instructors are attributes of the group.  They used to be members of a custom list (no longer available in Grouper).  In our API instructors also appear as members. Since our API runs searches against an LDAP cache rather than Grouper it can efficiently search by instructor.
Doing it over I'd use a separate group for instructors.

Read access is quite simple: members of a 'can read courses' group, and member of the course itself.

Our group service is not authoritative.  We only reflect what is in a separate student database.
That system sends course creation and membership events via AWS messaging.  We listen for these messages and create courses and update memberships as appropriate.  
Course groups are maintained for four quarters.  After that they are deleted.

I definitely agree with Blair that services ought to be driven by requirements.


On Jul 7, 2020, at 12:36 PM, Bill Thompson <> wrote:

Lafayette is working on getting our course rosters into Grouper. If you’ve already done this and have advice/regrets/pointers on things like naming convention, grouper privilege management, exception handling, course roster group lifecycle, etc please let me know.  We are pulling these in as reference groups per the Grouper Deployment Guide. Thanks!


Archive powered by MHonArc 2.6.19.

Top of Page