Grouper Developers Forum

[Tom Barton <>]

Rather than putting stem deletion or even more sophisticated conditional 
stem deletion into the API, to be used only by a system principal, can 
we aim instead to provide a contributed utility that Group Registry 
designers and operators can use to clean things up?

If that is reasonable from all perspectives, should we slot that for 
sometime after v0.6?

Tom

GW Brown, Information Systems and Computing wrote:
> I'm fairly sure that when I've asked about deleting stems that this has 
> been seen as problematical - I may have STEM privilege on 
> /uob/faculties, but not on /uob/faculties/artf/fren - or ADMIN privilege 
> on any groups in between.
>
> Renaming stems has similar problems - and there is the technical issue 
> of updating the stem attribute and displayName for all children in the 
> hierarchy.
>
> My feeling is that the System user probably ought to be able to delete / 
> move stems - and force deletion / movement of child stems and groups 
> recursively. When a repository is being designed it will be a real 
> nuisance if mistakes / changes of policies can't be rectified.
>
> So far in the UI I have included a delete stem option, however, if there 
> are > 100 children I don't allow it. Ideally, institutions ought to 
> decide their own policy. One way of doing this would be to add a 
> listener interface which has access to all children that would be 
> deleted and can veto deletion.
>
> Gary
>
>
>
> --On 17 March 2005 12:31 -0800 blair christensen 
> <>
>  wrote:
>
> > While cleaning up the Grouper test suite as part of making some larger
> > changes I realized that the API currently allows stems to be deleted.
> > I had *thought* we would allow groups to be deleted via the API but
> > not stems.  Unfortunately, I'm failing to find this stated anywhere.
> >
> > Is this a bug or is my recollection incorrect?
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing