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 On Mon, Sep 24, 2018 at 10:01 AM Hendrik Geßner <[email protected]> wrote: > 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 > > Am Dienstag, 18. September 2018 16:59:56 UTC+2 schrieb 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 >> >> >> On Tue, Sep 18, 2018 at 7:44 AM Hendrik Geßner <[email protected]> wrote: >> > 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 >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >> >> >>> 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 >> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-community. For more options, visit https://groups.google.com/d/optout.
