Grouper Developers Forum

[Shilen Patel <>]

> 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.


Should we also keep a history of the display names?  Before a group is  
moved, somebody might have an application that finds the group using  
the display name rather than the name.   The GroupNameFilter for  
instance allows that.  Realistically, I don't know if anybody would do  
that and if they do, maybe they should just be told to modify the  
application to search by group name prior to the move.


-- Shilen



On Dec 29, 2008, at 10:23 AM, 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.
>
> 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+Transition 
> >  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