Grouper Users - Open Discussion List

[Chris Hyzer <>]

I made a doc on grouper aliases (i.e. name history):

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+aliases

Also, what does this mean?

> copies are made to flesh out some scheme. For this, the copies have new
> identifiers and would optionally inherit memberships held by template
> elements.

You mean if someone is a member of a group which is copied, then that subject 
should be a member of the new copy of the group?  Agreed

And/or do you mean that if the group being copied is a member of another 
group or list, that the copy of the group should be a member of the group or 
list?  Unless there is a good reason for this, I'm not sure I agree with 
this.  Though if optional, then the caller can decide.

Thanks,
Chris


> -----Original Message-----
> From: Tom Barton 
> [mailto:]
> Sent: Monday, December 29, 2008 10:23 AM
> To: Shilen Patel
> Cc: Grouper Dev; 
> 
> Subject: Re: [grouper-dev] Namespace Transition
>
> Thanks for getting this started, Shilen.
>
> I imagine two general use cases. In one, copies are made as a
> convenience. A "template" group, stem, or hierarchy is created, and
> copies are made to flesh out some scheme. For this, the copies have new
> identifiers and would optionally inherit memberships held by template
> elements.
>
> The second general case occurs when the names originally chosen for
> some
> groups or stems need to change while maintaining references to the old
> names, at least for a while. This might occur because names of
> departments, teams, or organizations have changed (merged, split, or
> just renamed). It might also be due to a change in the authority of who
> can create what. For example, initially a group within the Dean's
> Office
> manages a group hierarchy for their College or Division, and after a
> while they decide to devolve group administration across parts of the
> organization. Depending on how they set things up initially, they might
> need to create new substems and move or copy groups and stems to the
> new
> ones as part of the hand-off of authority. Another example is a group
> created in a personal namespace that must move to an institutional stem
> to avoid being removed when the individual that created it leaves.
>
> Preserving references to old names is one of the reasons aliases are
> desirable. The alias doesn't change, so it's not as important to
> preserve a reference to an old name. UUIDs serve this purpose, but I
> suppose people don't like to use them because they are opaque. However,
> a flat alias namespace maintained by grouper users can suffer from the
> problems that led us to design stems in the first place: different
> people might create conflicting aliases, or one can create an alias
> that
> makes the group appear to be other than it is. Most people don't like
> opaque names and tend to read meaning into lucent ones.
>
> Whether or not we create an alias attribute of groups or stems, I
> wonder
> if it would be worthwhile when moving a group to maintain a list of its
> previous names in a system-maintained attribute of the group. Something
> like the SID history that Active Directory objects have. The way this
> would work is, when moving a group, the new one's name_history has its
> old name added in a manner that allows the group to be selected by
> either its new name or any of its old ones. Clearly, this only makes
> sense for moving and not for copies. In fact, a copy of a group would
> necessarily need to omit the old one's name_history.
>
> Tom
>
> Shilen Patel wrote:
> > Hi Folks,
> >
> > I'm working on creating a design for namespace transition support for
> > Grouper 1.5.0.   I've got some initial information available here.
> >
> >
> https://wiki.internet2.edu/confluence/display/GrouperWG/Namespace+Trans
> ition
> >
> >
> >
> > I'm very interested to know what your use cases are so we can make
> sure
> > our requirements cover them.  I'm not working from a pre-defined set
> of
> > requirements so I imagine they will be updated based on feedback.
> >
> >
> > Thanks!
> >
> > -- Shilen
> >