Grouper Developers Forum

[Tom Barton <>]

blair christensen wrote:
> 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

Although grouper models stems as groups, I don't think we've ever 
discussed whether access privs would apply to them and what they might 
mean. Since naming privs only are associated with stems, shouldn't we 
use one of those to determine stem-delete privilege? Probably 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]

Similar to comment above - stems-modeled-as-groups make no use of the 
members list, yes?

> * The stem is not a member of any other group or stem

Ditto.

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