Mark, Looking at this a bit further, I think your suggestion to "interpret the condition" may be best, as the Collection/Community is currently using that group for a very specific purpose (either as a Workflow Group, or as an Administrative group).
These types of Groups are actually *tied* to the Community/Collection directly (and named as such "COMMUNITY_<id>_*" or "COLLECTION_<id>_*"). So, it seems like the best route would be to require the group be 'unattached' or removed from the actual Community/Collection itself. There's another small oddity in this concept in that the Collection/Community APIs do not have a direct way to actually remove these groups (e.g. a 'deleteWorkflowGroup()' or 'deleteAdministrators()' would seem logical). Rather, it looks like the JSPUI and XMLUI take care of the cleanup after setting the group references to 'null' -- for example see FlowContainerUtils.processDeleteCollectionRole() (XMLUI) and EditCommunitiesServlet.processConfirmEditCollection() (JSPUI). - Tim On 8/25/2010 10:30 AM, Mark H. Wood wrote: > On Tue, Aug 24, 2010 at 02:37:43PM -0500, Tim Donohue wrote: >> Sounds like a bug to me -- it should remove the group for any >> Community/Collection assignments (in my opinion). > > Hmmm. Well, it cetainly should not do what it does now: pass along an > SQLException concerning violation of referential integrity. It could: > > o replace the assignment with NULL, which tighten restrictions on the > authorizations of the affected object (which IMHO is okay); or > > o interpret the condition: this Group cannot be deleted because > there are references to it. > > There's a question of whether we want Group silently tinkering with > these objects' authorizations. But it already silently tinkers with > other references, so I suppose the answer is "yes, delete() should > just work if at all possible." > > So I'm going to add a method 'authorizedFor(int)' to Community and > Collection, to provide the IDs of objects which reference the given > Group. > >> Not sure what that FIXME refers to (maybe checking user has the proper >> rights to *delete* the group, which doesn't seem to be checked at all -- >> likely another bug?). > > I'll leave the FIXME until someone explains it. > > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > > > > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
