Grouper Users - Open Discussion List

[Jeffrey Williams <>]

UNCG has had its courses pulled into Grouper since before I took it over. 

Folder design:
Current: YYYYMM folder model containing all course sections
Proposed: current/next/prev1/prev2 semester folder scheme.  Each containing all course section populations.  As time goes on, the next population moves into current groups without creating new group objects and potentially breaking downstream usage.

That way, downstream users hopefully have less work in maintaining access based on course membership.  They want those currently enrolled in CSC-440 access to a certain Jupyter Hub, they'll get access as soon as the current semester starts and lose it as soon as it's over.

Section Design: currently, we only do StudentOfRecord and TeacherOfRecord groups for each section.  Group ID's contain the semester in YYYYMM format and the course registration number e.g. SECTION___202008___81676-teachers. The display name has a more user-friendly DeptCode-CourseNumber-SectionNumber format(AAD-202-01-teachers-systemOfRecord). I don't think we've had any call for more granularity than that.  In pairing with the proposed folder design, I'd also drop the YYYYMM semester format and replace it with current/next/prev1/prev2.  

Department/Course roll-ups: Our current demand for roll-ups is at the semester level for teachers.  We've had a nibble about department-level current semester course roll-ups for access to departmental resources.  A straightforward SQL loader job against GROUPER_GROUPS in the Grouper database can set those up pretty quickly.  Depending on the scope of the population an access policy is looking for, using roll-ups may help policy admins get out of the business of checking to make sure their policies do contain all the sections that they should.  Depending on demand, course roll-ups probably should live in that dept's org:ref folder.

Exception handling:  That's currently being handled, as needed, at the access policy level today via exception groups.  I'd be interested to hear what others do in this area.

Group Lifecycling: I think if you understand the use cases you have for course groups, you can devise loaded roll-ups to suit.  Then, drive downstream use there.  Also, you can let semester folders only contain the actual sections for that semester and downstream users shouldn't have to worry if there's 46 or 2 sections of a course.  I'm thinking that unless you have access policies with very arbitrary needs at the section level, that should hit the 80% needs case.

-Jeff

On Tue, Jul 7, 2020 at 3:37 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

--

Jeffrey Williams 

Identity Engineer
Identity & Access Services
https://its.uncg.edu