DSpace 8.2 - Question about BITSTREAM_DEFAULT_READ group behaviour

[Julia Gilmore]

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) = 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