DELETE is dangerous

18 views
Skip to first unread message

Evgeni Dimitrov

unread,
Jun 29, 2016, 5:53:40 AM6/29/16
to dspac...@googlegroups.com
This is tested in DSpace 5.2 XMLUI

I have
- community "commA"
--- community "commB" inside it
----- collection "collC" inside it
------- item "itemD" inside it

I have an user "ucomma" with "admin" rights over "commA".

I am logged in as "ucomma".

Editing community "commA" - there is no "Delete" button.
Editing community "commB" - there is "Delete" button.

I clicked the "Delete" button, accepted the Warning that "all underlying items will be deleted", and got an error message:

Authorization denied for action REMOVE on COMMUNITY:13 by user 5

org.dspace.authorize.AuthorizeException: Authorization denied for action REMOVE on COMMUNITY:13 by user 5
    at org.dspace.authorize.AuthorizeManager.authorizeAction(AuthorizeManager.java:181)
    at org.dspace.authorize.AuthorizeManager.authorizeAction(AuthorizeManager.java:100)
    at org.dspace.content.Community.removeCollection(Community.java:1080)
    at org.dspace.content.Community.rawDelete(Community.java:1252)
    at org.dspace.content.Community.removeSubcommunity(Community.java:1168)
    at org.dspace.content.Community.delete(Community.java:1224)
    at org.dspace.app.xmlui.aspect.administrative.FlowContainerUtils.processDeleteCommunity(FlowContainerUtils.java:1017)
   
In addition to the error message something has changed and now:

the "DSpace Home" page shows two top level communities "commA" and "commB"
the "commA" page shows no subcommunities and no collections and "itemD" as recently submitted
the "commB" page shows collection "collC" and "itemD" as recently submitted
but shows as breadcrumbs DSpace Home -> commA -> commB
the "collC" page shows "itemD" as recently submitted
but shows as breadcrumbs DSpace Home -> commA -> commB -> collC

I think this is dangerous.
Two questions
1. Is there another place where bugs are reported?
2. What could be the workaround? May be to forbid to the community admins to delete subcommunities:
core.authorization.community-admin.delete-subelement = false

3. I have not tested will this work if I am logged in as system admin.

Tim Donohue

unread,
Jun 30, 2016, 3:31:20 PM6/30/16
to dspac...@googlegroups.com

Hi Evgeni,

To answer your questions..

1) Bugs can be reported via our issue tracker system at:  https://jira.duraspace.org/projects/DS     If you do not yet have a DuraSpace JIRA/Wiki account, you can request an invite by emailing sysa...@duraspace.org (unfortunately self signup has been disabled for now because of spam)

2) You definitely can disable the ability to let Community Administrators delete content.  The option you noted is the correct one:
core.authorization.community-admin.delete-subelement = false

3) A full system admin should be able to delete *any* content in the system, and should never receive a "Authorization denied" error.

I will note that I've not seen this bug before, which makes me wonder if there is something else that is going wrong.  If you have a test server, you might want to see if you can reproduce this problem by having a Community Admin delete a different sub-community (and seeing what happens).  If others have encountered this before, hopefully they will speak up.

I'll also note that, either way, this should be fixed in the upcoming 6.0 release (due in the next few weeks or so). In 6.0, we've added Integration Tests which specifically validate all delete capabilities of Community / Collection Admins.  They were added as part of this recent code change: https://github.com/DSpace/DSpace/pull/1447    But, unfortunately, these same tests are not valid to backport to 5.x (as there were significant API level changes between 5.x and 6).  But, going forward, these automated tests mean that future issues with deletions will be much less likely to ever occur.

Tim

--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

Evgeni Dimitrov

unread,
Jun 30, 2016, 4:06:42 PM6/30/16
to DSpace Technical Support
Thank you Tim,

I was runnung this on a test server and I deleted the affected communities (as system admin), created again and tried again (as community admin) and failed the same way. I will request an invite for JIRA/Wiki, but will not report this and will retest with the 6.0 release.

Best regards
Evgeni


On Thursday, June 30, 2016 at 10:31:20 PM UTC+3, Tim Donohue wrote:

Hi Evgeni,

To answer your questions..

1) Bugs can be reported via our issue tracker system at:  https://jira.duraspace.org/projects/DS     If you do not yet have a DuraSpace JIRA/Wiki account, you can request an invite by emailing . . . (unfortunately self signup has been disabled for now because of spam)

To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscribe@googlegroups.com.

To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages