On Wed, Aug 25, 2010 at 11:55:40AM -0500, Tim Donohue wrote: > 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.
You mean, removed by explicit, separate human action? That would play
hob with 'dsrun packager -r -f -t AIP -i prefix/0' since it wants to
first delete an existing group and then create it from the package.
(One supposes that the assignments would be restored when the object
carrying them is restored later.)
However, the AIP ingestion code could clean out the group assignments
itself instead of expecting Group.delete() to do it. That would let
Group be defensive since it knows less about the intent of the call.
Hah, there may be a smarter way to do this. I should just empty the
*Group* of its members and then refill it from the package. That way
the Group is never destroyed. Group is much simpler and more regular
inside than the other objects in a package, so it makes some sense to
reuse its "skin" with different "stuffing".
So, does anybody want the 'authorizedFor' methods I already wrote for
Community and Collection? They're not yet committed anywhere.
> 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).
Actually, Community.removeAdministrators() does exist, as do
Collection.removeAdministrators() and Collection.removeSubmitters().
But I guess they aren't used? There is no
Collection.removeWorkflowGroup(int) but as you say it does accept null.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Balance your desire for bells and whistles with the reality that only a
little more than 2 percent of world population has broadband.
-- Ledford and Tyler, _Google Analytics 2.0_
pgpA7M7GeOs4v.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
