Restrict default bitstream access

[Hendrik Geßner]

Hello everyone,

I currently try to restrict the default access to bitstreams in DSpace 6.3 without restricting access to the item (and its metadata). So if there is a "main group" and a "special group" that is part of "main group", an item should be readable by all members of "main group", but the bitstreams should only be accessible by members of "special group".

My collection has the following authorization policy:

ADD                      foobar_WORKFLOW_STEP_2

WORKFLOW_STEP_2          foobar_WORKFLOW_STEP_2

ADD                      special group

DEFAULT_BITSTREAM_READ   special group

READ                  main group

DEFAULT_ITEM_READ        main group

When submitting an item, it gets the following authorization policies:

Item Policies

READ   main group

Policies for Bundle ORIGINAL

READ   special group

Bitstream Article.pdf

READ   special group

READ   main group

The last line, READ "main group" for the article, should not be there, but if I change the DEFAULT_ITEM_READ to "special group" then the item policy lacks a READ "main_group" from the first line. What am I missing here?

Kind regards,

Hendrik Geßner

[Tim Donohue]

Hi Hendrik,

I'm not able to reproduce this behavior on our Demo Site (http://demo.dspace.org/jspui/), running v6.3.  So, I wonder if you've changed something locally that could be affecting this?

A quick note:
* First, it seems testing this is only possible in the JSPUI. I don't see a way to even *set* "DEFAULT_BITSTREAM_READ" policies on a Collection in the XMLUI  (But maybe I overlooked it)

Here's what I tried:
1) I created a Collection and added "DEFAULT_BITSTREAM_READ=SubGroup" and "DEFAULT_ITEM_READ=Main Group" to that Collection. Here it is: http://demo.dspace.org/jspui/handle/10673/128

2) I submitted a new Item (with a single "test_pdf.pdf" bitstream) into this Collection.  It's policies (after submitting) are: 
     * Item READ policy = "Main Group"
     * Bundle (Original) READ policy = "SubGroup"

     * Bitstream (test_pdf.pdf) READ policy = "SubGroup"

    Here's that test Item that I created: http://demo.dspace.org/xmlui/handle/10673/131 

So, I'm seeing the permissions applied properly in 6.3.  You are welcome to also try this out yourself on the demo site, in case I overlooked something.

If you have more information or notice something that we've missed, let us know on this mailing list.

Tim

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-communi...@googlegroups.com.
To post to this group, send email to dspace-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-community.
For more options, visit https://groups.google.com/d/optout.

--

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

[Hendrik Geßner]

Hello Tim,

we use XMLUI, user rights can be modified in "Edit Collection -> Assign Roles -> Edit authorization policies directly." which is present in our local installation, but not on the demo site. I tried to retrace the problem by downloading and installing a fresh DSpace 6.3 release instance. When using the default settings everything works as expected but when switching item-submissions.xml Step 4 to "Upload Item with Embargo Features" I could reproduce the problem immediately.

Kind regards,
Hendrik

[Tim Donohue]

Hi Hendrik,

I'd recommend creating a new bug ticket in our JIRA system (https://jira.duraspace.org/projects/DS/), noting the exact steps you had to take to see this problem occur.  It is starting to sound like this may be a bug that exists *only when* "Upload Item with Embargo Features" is enabled.  So, it may not occur in all instances (like the demo site, which doesn't have that step enabled), and it may even be a bug in that embargo step.   If we can list out the exact steps to reproduce the error, then it will be much easier for a volunteer to dig deeper and determine where the bug exists.

Thanks for continuing to dig on this.  It definitely is sounding more and more like a bug to me.

Tim

[Hendrik Geßner]

Hi Tim,

the bug report is available at https://jira.duraspace.org/browse/DS-4017

Kind regards,
Hendrik