Grouper Users - Open Discussion List

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

--On 29 December 2008 09:23 -0600 Tom Barton 
<>
 wrote:

> 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.
Sometimes it will be fine if the extension / display extensions are copied 
verbatim, however, it may be useful to have a means of changing the 
extensions as they are copied e.g. prefix / suffix / regular expression / 
interface. In general I like to have unique extensions - though in the 
QuickStart we don't.
> 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.
We did some custom development to implement aliases for stems. In part this 
was so we weren't restricted to one hierarchy e.g. we could have an 
alphabetical listing of departments as well as the organisational 
hierarchy, and, in some cases i.e. joint honours, some course modules would 
ideally be accessible from the two departments concerned. Our 
implementation (which used a naming convention, so I wouldn't recommend 
using it in the API), did allow the UI to show the aliases and would, in 
fact, work like a UNIX ln -s so the path displayed to the user would 
reflect how the user got to a location (with an option to 'relocate').
> 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+Transi
> > tion
> >
> >
> >
> > 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



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