Grouper Developers Forum

[Tom Barton <>]

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?

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

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