Grouper Developers Forum

[Shilen Patel <>]

On Mar 19, 2009, at 2:36 PM, Tom Barton wrote:

> Chris Hyzer wrote:
> > As Shilen said in a different email, the user can rename the group to
> > something, and name it back (thus setting the previous name).
> > Allowing to just set the previous name to an arbitrary name (that
> > they have privileges in the folder for), is just a shortcut so
> > Grouper doesn't have to move all those memberships around and back...
>
> Aside: must memberships be touched when a group is moved? Isn't that  
> just a property of the group object - it's still the same group?

Memberships aren't touched when a group is moved. :)


> > Therefore I don't think we need a restore-previous-name command, or a
> > check to see if it was a previous name, since there is a workaround,
> > we are just saving some time...  also I don't think we need an admin
> > only operation since you don't have to be an admin to move a group
> > and move it back, right?
>
> The group's ADMIN, is the Admin I meant. That would be consistent  
> with the existing security model, I think, for protecting a restore- 
> previous-name command. Shilen has already detailed the priv checking  
> for the other operations.
>
> > The only thing that is weird for me, is if you can assign a previous
> > name, and it wasn't a true previous name, should we still call it
> > "previous name".  Im ok with keeping it that way, it is just not
> > precise...
>
> So let's call it an alias, or an alternate name, and be clear that  
> we're *not* attempting to nail the problem of minimizing disruption  
> when groups and stems are moved around.


If we go with the addPreviousName() route, I think calling it an  
alternate name might be better than alias since alias would suggest  
more functionality that what we're doing.

Thanks!

-- Shilen



> Tom
>
> > Thanks,
> > Chris
> > > -----Original Message-----
> > > From: Tom Barton 
> > > [mailto:]
> > > Sent: Thursday, March 19, 2009 2:00 PM
> > > To: Shilen Patel
> > > Cc: Chris Hyzer; Tom Zeller; Grouper Dev
> > > Subject: Re: [grouper-dev] findByName
> > >
> > > How would you check to see if the value was in fact a previous name?
> > >
> > > I'm still confused about the problem we claim to be solving. Is it  
> > > to
> > > preserve old references to a group or stem to minimize disruption  
> > > when
> > > moving things, or is it to provide a general aliasing capability  
> > > whose
> > > default behavior preserves the last old reference, but can be used
> > > otherwise?
> > >
> > > I'm ok if we decide it's the latter, but recognize that it can't be
> > > used
> > > for both aliasing and preserving an old reference at the same  
> > > time. So
> > > we might find sites still wanting a solution to the former, even  
> > > after
> > > we've delivered the latter.
> > >
> > > If it's the former and if there's a way to determine the previous  
> > > name,
> > > then group.addPreviousName() really becomes  
> > > group.restorePreviousName()
> > > and I'd say that the group's Admin can do that.
> > >
> > > If it's the latter, then something rather complicated like Shilen
> > > proposed is necessary. The Subject assigning an alias must have the
> > > privilege to create names with the stem used in the alias, or in the
> > > root stem if there's no stem in the alias.
> > >
> > > Unless of course it's to be a "true" alias capability, ie, not
> > > restricted to assigning names based on grouper's naming stems. That
> > > would amount to having a new flat namespace added to grouper,  
> > > something
> > > I've carefully avoided from inception of the project. Should we  
> > > revisit
> > > that ancient assumption?
> > >
> > > Tom
> > >
> > > Shilen Patel wrote:
> > > > Then do we actually check to see if the previous name being added  
> > > > was
> > > > actually a previous name for the group?  If not, then what type of
> > > > privilege checking should we do?  In addition to having ADMIN on  
> > > > the
> > > > group, perhaps the person should have CREATE access to the stem  
> > > > that
> > > > contained the previous name.  And if that stem doesn't exist, we  
> > > > just
> > > > walk up the hierarchy until we find a stem that does exist and then
> > > > verify the CREATE privilege.
> > > >
> > > > Would that work?
> > > >
> > > > Thanks!
> > > >
> > > > -- Shilen
> > > >
> > > >
> > > > On Mar 19, 2009, at 10:48 AM, Chris Hyzer wrote:
> > > >
> > > > > Cant we just have a group.addPreviousName(name) [which currently
> > > > > replaces the current one] and group.deletePreviousName(name)?  if
> > > > > someone tries to use a previous name which is removed, then they
> > > just
> > > > > add it back.  If it is a question as to whether they know what the
> > > > > name is, cant they look in the logs to see where the error is
> > > > > occurring?  And yes, I think we can assume people will use  
> > > > > auditing,
> > > > > and if they don't want to, we don't need to code around it.
> > > > >
> > > > > These methods can be callable by GSH, and I can expose them via WS
> > > and
> > > > > client fairly easily with the save group service (in the detail
> > > portion)
> > > > > Thanks,
> > > > > Chris
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Shilen Patel 
> > > > > > [mailto:]
> > > > > > Sent: Thursday, March 19, 2009 7:56 AM
> > > > > > To: Tom Zeller
> > > > > > Cc: Grouper Dev
> > > > > > Subject: Re: [grouper-dev] findByName
> > > > > >
> > > > > > Based on what I was hearing in previous discussions, this didn't
> > > seem
> > > > > > to be very important.  Even though people might stop using the
> > > > > > previous name, having it remain in the system might not do any
> > > harm.
> > > > > > However, we can add the option to remove it if you think it would
> > > be
> > > > > > useful.  But there may be more to consider.
> > > > > >
> > > > > > So say if somebody removes a previous name then realizes that  
> > > > > > it's
> > > > > > still being used and so the user wants to add the previous name
> > > back.
> > > > > > How does that get handled?
> > > > > >
> > > > > > One way might be to always populate the previous_name column but
> > > also
> > > > > > have another column (previous_name_searchable) that determines if
> > > the
> > > > > > group can actually be found using the previous name.   The new
> > > column
> > > > > > can be turned on and off by admins of the group.  But if our  
> > > > > > future
> > > > > > method of doing multi-valued attributes won't be able to handle
> > > this,
> > > > > > then we might need a separate table for this data after all.
> > > > > >
> > > > > > Another way might be to let admins of a group add back previous
> > > names
> > > > > > based on audit data if that information is easy to query.  But
> > > > > > everyone might not be using audit.
> > > > > >
> > > > > > Perhaps we just give the user a warning saying that once you  
> > > > > > remove
> > > > > > the previous name, you cannot add it back (unless you go directly
> > > into
> > > > > > the database of course).
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > -- Shilen
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mar 18, 2009, at 4:14 PM, Tom Zeller wrote:
> > > > > >
> > > > > > > Are we also providing a method to remove previous name(s) ?
> > > > > > >
> > > > > > > TomZ