Hi DSpace community, 

Apologies for cross-posting this from the DSpace Slack. We're curious about 
some of the behaviour we've noticed using the DEFAULT_BITSTREAM_READ group 
to restrict access to items in a particular collection on a DSpace 8.2 
instance. 

What we did: 

   - Edited the collection that we wanted to restrict access to
   - From the Assign Roles tab, we selected the 'Restrict' button for 
   'Default bitstream read access' and assigned an 'Authenticated ' group 
   (anyone logging in via institutional SSO receives the Authenticated group 
   permissions) 

What we noticed:

   - Access is restricted to Bundle:ORIGINAL bitstreams for any new items 
   deposited to the collection. A lock icon displays beside the file name for 
   non-authenticated users.
   - A 'Restricted' label appear on the item (we customized the label name 
   to say 'Authenticated' but it refers to the same type of access condition 
   <https://github.com/DSpace/dspace-angular/issues/1566>) = all of this is 
   great! 

*The first wrinkle* we encountered happened when we tried to edit the 
DEFAULT_BITSTREAM_READ group and assign the Anonymous group (we wanted to 
test changing/opening up access to the collection, which might be a need in 
the future). 

We can update/save the changes to the group and new items' bitstreams are 
available (i.e, not restricted) but the items still get the 'Authenticated' 
(Restricted) label when they should get the 'Archived' label indicating 
they are open access. It's as if the label is stuck and we are curious if 
the Authenticated label is showing because we explicitly defined a 'Default 
bitstream read access' group?

*The second wrinkle *we noticed was that when we change the 
DEFAULT_BITSTREAM_READ group back to 'Authenticated', any bitstreams that 
were previously unrestricted (because the item was created when the READ 
access was set to Anonymous) are now restricted and have a lock icon. When 
we change the group to 'Anonymous', they become open again (the lock icon 
disappears). This seems to contradict the expected behaviour for the group 
as described on the Assign Roles page: "Changes to this role are not 
retroactive. Existing bitstreams in the system will still be viewable by 
those who had read access at the time of their addition.

If anyone has any insights based on experiences using the default read 
access groups to set collection-level access, we would welcome any feedback 
or suggestions. 

Thanks! 

Julia 

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://lyrasis.org/code-of-conduct/
--- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/dspace-tech/11b40423-c8f3-44fe-8fe0-1c774037e9acn%40googlegroups.com.

Reply via email to