Permissions in DSpace 7.x

[Yvonne Jeannine]

Hello Community!

We've been using DSpace for a consortial repository since 2017, with about 64 different campuses sharing the space--each campus as a top-level community. During that time, we managed the admins as campus groups, assigning admin users to each campus community, which gave them access to create subcommunities and collections within their top-level campus communities, but did not give them access to other top-level communities.

Since our migration from DSpace version 6.3 to 7.4, we are seeing a lot of odd things happening. Most of the old campus admin groups were wiped from the top-level communities and I had to create new campus admin groups. However, these are not working as they once did. I'm finding that newly added campus community admins have access to edit and create top-level communities and subcommunities/collections throughout the repository, not only within their own campus areas. At the same time, these newly created admins are unable to add items to already existing collections in their own campus communities.

Is this normal behavior for version 7.x? Do I need to do a thorough audit of all permissions in this (very large) repository? Does anyone out there have experience running DSpace in a consortial environment in this way?

Thank you for any and all input!

Sincerely,

Yvonne Kester

Repositories Manager

SUNY Library Services

[Chapman, Kimberly A - (kimberlychapman)]

Hello Yvonne,

 

That’s very interesting! I have no idea what the answer is, but I am going to test that in DSpace 8.0 during this week’s testathon.

 

The testathon discovered a problem with Registering for the repository, and that is being fixed and deployed today – I think this will make it much easier for me to test things like this (because being limited to the default testing personas gets confusing when trying to distinguish between permissions, etc.)

 

All best,

 

Kimberly

 

From: dspace-c...@googlegroups.com <dspace-c...@googlegroups.com> On Behalf Of Yvonne Jeannine
Sent: Monday, April 15, 2024 9:23 AM
To: DSpace Community <dspace-c...@googlegroups.com>
Subject: [EXT][dspace-community] Permissions in DSpace 7.x

 

External Email

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
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 view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/CAKZKP2D87gUGRj4gSMLJQmhRTynseKS7y46ZGkdgMVMpUct4yg%40mail.gmail.com.

[Yvonne Jeannine]

Thank you Kimberly!

[Kimberly Chapman]

Hi Yvonne,

I've been playing around with this in both the DSpace 8 sandbox (sandbox.dspace.org) and the DSpace 7 demo site (demo.dspace.org).

I used the "dspacede...@gmail.com" persona to create these scenarios:

Scenario 1:

- Top-Level Community 1: community administrator = Moxie Woxie (my cat's name with my work email account)

- Top-Level Community 2: community administrator = Oliver Rooney (my cat's name with my gmail account)

Results:

Both Moxie and Oliver could create new communities / collections within their assigned communities.

They could not:

• create new top-level communities
• create collections or subcommunities outside of the assigned community
  

Scenario 2:

- I removed Oliver Rooney as an individual community administrator

- As system administrator I created a new group for the Top-Level Community 2

- I added Oliver Rooney to that Group

- I added that Group as the community administrator for Top-Level Community 2

Results:

Oliver could create new communities / collections within his assigned community

Oliver could not:

• create new top-level communities
• create collections or subcommunities outside of his assigned community

I do think the UI could be improved because during my tests it LOOKED like Moxie and Oliver could create top-level communities and create new communities/collections in communities where they did not have assigned roles. Their personas could add a title, description, etc. on new community and collection pages. However, when saving the information, the red pop-up "Server Error Access Denied" message consistently appeared on the upper right corner and no collections/communities were created where they didn't have permissions. (Which is what I would expect.) I also tried to have the Oliver persona edit other people's communities and that didn't work either - again, that's what I would expect.

• Most users I work with think "server error" means that they are supposed to be able to do something and that something wrong has happened with the system.
  
• The "Access Denied" piece is a little more clear, it's a hint that hey, you don't have access.
  
• I think some thought about a clearer error message would be an improvement.
  
• Ideally, it would be nice if a user who didn't have authorization wouldn't be able to enter any data and would get an authorization error message sooner in the process, not after they've filled out the information for a new community/collection that they aren't authorized to create. (I don't know if that is even possible.)

On the downside, I cannot replicate your issue. On the upside, DSpace 7 demo and DSpace 8 are behaving as I would expect.

I hope someone who currently manages a DSpace 7.X repository can provide some ideas for you to find out why community administrators are getting access that they should not have, post-migration to DSpace 7.x. That sounds like a big problem to me! Maybe it's something you can screenshot or record, and submit a GitHub ticket. I'm adding permissions audit to my list of migration/post-migrations tasks - it doesn't sound like I have nearly the range & scale of permissions that you have in your consortial setup, but we do have plenty of campus collection managers that have limited permissions (which should remain limited.)

All best,

Kimberly

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/CAKZKP2DDkUNJDExiOnGMiMMtWaM0PoZT3AcPtyBbd8LbBWpgWg%40mail.gmail.com.

[Yvonne Jeannine]

Hello Kimberly,

Thank you so much for your (and your sweet kitties!) very thorough testing. I should have done more thorough testing myself, but when I saw that campus admins had access to all the top-level communities I took it at face value. I realize now that indeed, it gives the appearance of giving access, but won't allow actual work in those areas not specifically assigned.

I love your cats' names! I once had a cat named Tom Bombadil. 🙂

There are other things I need to look at, and will respond off list when I get the chance to do so. Thank you again for your troubleshooting work!

Best regards,

Yvonne

[Chapman, Kimberly A - (kimberlychapman)]

Thanks for the feedback, Yvonne.

 

I’m glad this was helpful.

 

I still think there is a User Experience issue here to address and I’ll be submitting that feedback as part of the Testathon. (I’m not expecting any changes to make it into DSpace 8 but reporting the UX issues for future attention is useful. I also expect that this is the type of UX feedback that the DCAT UX Working Group will document when they start their work later this year.)

 

All best,

 

Kimberly