On 8/25/2010 1:38 PM, Mark H. Wood wrote: > 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".
Yes -- in terms of the AIP packager code to replace existing groups, you probably should just empty out the existing group and re-add it's members. That old idea of actually deleting & recreating objects from scratch during an AIP replace had to be 'scrapped' along the way anyways (for the Community/Collection/Item AIPs). The AIP replace method now always attempts an in-place replace (by first clearing out the object's info, and then replacing it with whatever is in the AIP). The reason the 'delete & recreate' approach wouldn't work properly is that it caused problems with Communities & Collections (esp. Collections). Actually removing that structure and recreating it from scratch caused some unanticipated issues to pop up (e.g. you'd be accidentally wiping out all existing WorkspaceItems & WorkflowItems by accident during a Collection replace). So, I had to implement it differently to avoid those areas of potential data loss. >> 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. My mistake -- overlooked that some of those 'remove' methods do exist (and on second glance the ones that exist are used by the XMLUI & JSPUI). It's just the 'removeWorkflowGroup()' that is seemingly missing, thus causing the XMLUI & JSPUI to implement its functionality themselves. It also seems odd to me that 'removeAdministrators()' and 'removeSubmitters()' do not actually remove the group itself...it just sets the group reference to NULL. This seems odd & messy, as you are then relying on every DSpace Interface to then realize that the Group itself needs to be deleted. - Tim ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
