Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 05 February 2009 08:51 -0600 Tom Barton 
<>
 wrote:

> 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?
In principle yes - a course module might be available in several courses
> > 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



----------------------
GW Brown, Information Systems and Computing