Grouper Developers Forum

[Tom Barton <>]

GW Brown, Information Systems and Computing wrote:
> My use cases for stem aliases are similar:
> 1) Supporting multiple hierarchies so that stems/groups can be found 
> straightforwardly by individuals with different roles and, therefore, 
> different expectations - this is similar to Bert's use case where 
> department members have different needs to a sys admin.
>
> 2) Sometimes a strict hierarchy just doesn't work - we have course 
> modules which may be taken by students on different courses from 
> different departments. From the Staff or Student point of view groups 
> associated with the module belong under both department/course trees. 
> This is more a navigation issue than wanting stem aliases to be 
> interchangeable in config files.

Would this require multiple aliases per stem?

> Given that course modules etc will often be represented by more than one 
> group it is often more appropriate to create a stem alias than lots of 
> group aliases. I understand there are more implications for stem aliases 
> but it has been on my wish list from the very first call Bristol had 
> with Tom and blair when we got involved with Grouper - more consistency 
> Tom :)

I've noticed!

> > Btw, might there be grouper configuration that breaks due to someone
> > renaming something?
> >
> > e.g. the ldap provisioning example where the provisioned groups are from
> > a stem in the ldappc.xml file, if someone moves that, then those might
> > not get provisioned… if there is an alias, then it might, if it is sql
> > driven, then it might not.

I think this is more of a documentation issue than one needing a 
technical remedy. Further, Stem privs limit where a particular Subject 
can move things to (and renames stay in the same parent stem). So even a 
strictly stem-based provisioning strategy can work just fine.

The only real risk comes from those who have no limits on how they can 
modify things, which is as it is now.

Tom