Grouper Users - Open Discussion List

[Steven Carmody <>]

We have LOTS of groups of the type that you describe, and we use the 
processes you describe to address the problem I'm worried about. We 
currently have > 1M groups in Grouper.

But, since we've now given 200+ depts the authority to create and manage 
adhoc groups, we have a harder problem to address. The adhoc groups are 
typically Project teams (drawing people from several depts) or research 
team groups (often including undergraduates -- that's part of the Brown 
culture; and often including external users -- a different and also very 
hard problem). Unfortunately, these are truly adhoc groups.

I suspect the problem will only get worse when, in a couple of years, we 
allow everyone to create their own personal adhoc groups.

On 5/8/15 4:09 PM, Julio Polo wrote:
> Are your groups really ad hoc or are they usually well-defined groups
> such as "employees of the office of information technology" with some
> exceptions?   This all hinges on your having something that
> automatically keeps these well-defined groups in sync.  For example, we
> have a group store where we offer app developers groups based on roles
> (faculty, staff, student), department, campus, system of record.  The
> groups in the group store are automatically updated as our IDM system
> gets data from the systems of record.
>
> In this scenario, you would create a composite group:  ("employees of IT
> department" from the group store UNION "a group for manual inclusions")
> COMPLEMENT "a group for manual exclusions"  If a person leaves that IT
> department, he or she is no longer a member of the composite group, and
> therefore no longer has access to whatever is controlled by that
> composite group.  The tricky part is setting rules for dealing with the
> manual inclusions/exclusions.