Hi all, I'm working on http://jira.dspace.org/jira/browse/DS-270
I'm pretty near to a solution but I need to take a decision about how manage the deletion of subcommunity/collection. The goal is to make configurable if a "local" admin (community/collection) is allowed to remove his subcommunities, collections and items. The problem is that the Community.removeCollection but also Community.removeSubCommunity and Collection.removeItem drop the relation with here parent at the start of the procedure so, if the "subelement" is an orphan, we can't more derive permissions from the parent. If you take a look a the current code you will see comments like this > //make the right to remove the item explicit because the implicit > // relation > //has been removed. This only has to concern the > currentUser > // because > //he started the removal process and he will end it too. > //also add right to remove from the item to remove > it's bundles. > AuthorizeManager.addPolicy(ourContext, item, > Constants.DELETE, > ourContext.getCurrentUser()); > AuthorizeManager.addPolicy(ourContext, item, > Constants.REMOVE, > ourContext.getCurrentUser()); > > // Orphan; delete it > item.delete(); I see two options here: 1) we can go on with the current practise of manually add all the permissions that we would inherited from the parent but this will make the remove method less clear and the authorization logic more scattered 2) we can check for subelement that will become orphan before, and subsequently remove them. Deferring at the end the drop of the relation. In this case we will need to defer the constraint check (for example community2collection_collection_id_fkey on table "community2collection" ) during the subelement deletion. What do you think? could be appropriate use constraint deferring? Thanks for you suggestion, Andrea -- Dott. Andrea Bollini Project Manager, IT Architect & Systems Integrator Sezione Servizi per le Biblioteche e l'Editoria Elettronica CILEA, http://www.cilea.it tel. +39 06-59292853 cel. +39 348-8277525 --- Disclaimer: the content of this email is confidential and may be privileged, and it must not be disclosed or copied without the sender's consent. If you have received this message in error, please notify the sender and remove it from your system. The content of this email does not constitute legal advice, nor any responsibility is accepted for loss or damage incurred as a result of acting upon its contents or attachments. The statements and opinions expressed in this email are those of the author and do not necessarily reflect those of the employer. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
