Grouper Users - Open Discussion List

[Tom Barton <>]

We're still developing "grouper as a service", which in particular will
mean that departments can get themselves setup without necessarily
needing involvement of the central idm team. However, we have setup
several departments with a folder and given them STEM privilege there so
they can create whatever they like and delegate to whomever they like.
We haven't tried to prescribe anything about what they'll choose to do
there. We do make some departmentally-oriented groups available to them
that are determined from core business systems and maintained in the
top-level "reference" folder.

Some of this is hinted at in our naming plan:

https://wiki.uchicago.edu/display/idm/Group+Names

Tom

On 8/23/2011 9:53 AM, Steven Carmody wrote:
> I'm seeking thoughts and experience. Let me provide some background 
> information, and our current thoughts. However, I'm really looking to 
> start a conversation, and hear what other people are thinking.
>
> We've begun to walk down the road to providing departments with 
> department-related groups. We're expecting to provide 1) some 
> auto-magically provisioned groups using information from various 
> Business systems, and 2) delegate to the department the authority to 
> create and manage groups for their specific needs. Beyond that, of 
> course, we have the usual range of departments, from very small to very 
> large, including both administrative and academic. So there's a wide 
> span of requirements and complexity.
>
> Having spent too many years with naming hierarchies of various sorts, my 
> initial inclination is to provide a small standard set of top level 
> containers within each department container. Having a single flat name 
> space at the top level frankly gives me a bad sort of itch; I think our 
> experience with file systems, etc gives us enough hints about the types 
> of groups people will want that we can make some educated guesses about 
> "categories". OTOH, we don't want to over-prescribe a single framework 
> on everyone, and we don't want to force a deep multi-level hierarchy on 
> everyone.
>
> We're currently thinking of this set of top level containers:
>
> -- People (this would contain auto-provisioned groups like Faculty, 
> Staff, Grad Students, Concentrators, student workers, etc). The dept 
> could manage groups containing "affiliated faculty" (eg people in other 
> depts who aren't official members of this dept but are considered to be 
> unofficial members of this dept; some affiliates could be from other 
> campuses);
>
> This container would likely also contain groups related to the 
> administrative structure of the dept. In all likelihood, these would 
> have to be manually maintained by the dept.
>
> -- Projects This would contain groups related to various Projects that 
> the dept is involved with; many of these could contain people from other 
> depts; research groups could contain people from other campuses. The 
> dept would be authorized to manage everything in this container. We're 
> assuming that a Research group would create their own container and 
> namespace within this container.
>
> -- Applications (or Services). This would contain groups that have 
> various privileges within centrally-offered services (eg who can 
> edit/approve changes to the dept web site on the central web server). We 
> expect that each application will include a "grouper-lite-lite" GUI 
> allowing an admin to browse and manage memberships relevant to this 
> application. These groups are placed in a well-defined location so that 
> the relevant application can find them.
>
> -- Other (love that name...) The dept can do whatever they want within 
> this container...
>
> -- a dept can also ask us to create additional top level containers for 
> their use.
>
> -- Note that Course-related groups are placed elsewhere in the hierarchy.
>
> So... what are other sites doing with departmentally-related groups ?