Grouper Users - Open Discussion List

[Jeff McCullough <>]

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?

Jeff

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,

 course:<YYYY><QQQ>-<CURRICULUM><NUMBER><SECTION>

 (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.

Jim

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!

Best,

Bill