Grouper Developers Forum

[blair christensen <>]

On 2005.03.18 08:06, Tom Barton wrote:
> Rather than putting stem deletion or even more sophisticated conditional 
> stem deletion into the API

Rather than taking out stem deletion (for now), I've left it in (as
part of the GrouperGroup/GrouperStem split and fleshed out a little
further the requirements that must be met to permit stem deletion.  As
of some code I checked in a couple of days ago, stems can be deleted
if:

* One has ADMIN on the stem
* The stem does not contain any child stems [0]
* The stem does not contain any child groups [1]
* The stem does not have any members [2]
* The stem is not a member of any other group or stem

> can we aim instead to provide a contributed utility that Group Registry 
> designers and operators can use to clean things up?

This is also an option but I wonder if it is needed.

> GW Brown, Information Systems and Computing wrote:
> >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.

I sort of like this idea.  I'll have to think about it further.

blair.

[0] Now available via GrouperStem's stems() instance method
[1] Now available via GrouperStem's groups() instance method
[2] This one sort of bothers me but I can't decide how much