A growing number of Properties have to be "set" when creating and managing a group in Brown's Grouper instance. Examples include: which target directories to replicate this group to, what properties it should have in each target system, what properties it should have in Grouper, etc. As we delegate out to Depts the authority to create and manage their groups, we're looking to provide them with an "easier" way to set these properties. The currently most popular suggestion is to define a set of "Categories", and allow Group Admins to assign a group to a Category. Each Category type would have a pre-defined set of properties which would then be applied to the group; some of these would affect target systems, some would affect the group in Grouper itself. Example Category values include: Course, Dept-People-Groups, Service Groups, Project-Open, Project-Private. There would be a standard set of Properties that would have to be implemented in each target directory.
We currently use a MSG BUS (ActiveMQ in our case) to 1) have business systems update group memberships in Grouper, and 2) replicate changes in Grouper into target operational directories. We would like to see a "standard" message format on the BUS, and would like to see Grouper include a core set of listeners (eg ldap, AD, google, canvas?, group itself). One of the fields in these messages would be the Category value. Each listener would "implement" that Category in its target directory for the group referenced by the MSG.
We're now pushing data from several campus business systems into Grouper; from there we're replicating group memberships (in real time) into several target systems (ldap, LMS (Canvas), Google, Active Directory).
We have several different categories of groups whose base membership is managed in this way (community/demographic groups, departmental people groups (English-Faculty-All, English-Staff-All, etc), Course Groups, undergraduate concentration groups, etc).
As more and more people use these groups, we're finding that we have to set Properties on these groups in some target systems. And, not surprisingly, the values we set are a function of the "category" that a group belongs to.
With Course groups, not surprisingly, we have to worry about FERPA constraints. With google the defaults work OK; with AD, we have to do a bizarre dance to get the correct outcome. With departmental people groups, we have to change the properties in google so that admin staff can schedule faculty meetings and see the responses.
We suspect we're not the only campus starting to deal with this issue. The way I've described this ("categories of groups") implies how we're thinking to approach the problem. Grouper sends messages to connectors (to the target systems); those messages would now include a "category value".