Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Deleting stems?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Deleting stems?

Chronological Thread 
  • From: Tom Barton <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc:
  • Subject: Re: [grouper-dev] Deleting stems?
  • Date: Fri, 18 Mar 2005 08:06:06 -0600

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?


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.


--On 17 March 2005 12:31 -0800 blair christensen

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

Archive powered by MHonArc 2.6.16.

Top of Page