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 "[email protected]" 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 On Mon, Apr 15, 2024 at 10:39 AM Yvonne Jeannine <[email protected]> wrote: > Thank you Kimberly! > > On Mon, Apr 15, 2024 at 1:00 PM Chapman, Kimberly A - (kimberlychapman) < > [email protected]> wrote: > >> 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:* [email protected] < >> [email protected]> *On Behalf Of *Yvonne Jeannine >> *Sent:* Monday, April 15, 2024 9:23 AM >> *To:* DSpace Community <[email protected]> >> *Subject:* [EXT][dspace-community] Permissions in DSpace 7.x >> >> >> >> *External Email* >> >> 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 >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/dspace-community/CAKZKP2D87gUGRj4gSMLJQmhRTynseKS7y46ZGkdgMVMpUct4yg%40mail.gmail.com >> <https://groups.google.com/d/msgid/dspace-community/CAKZKP2D87gUGRj4gSMLJQmhRTynseKS7y46ZGkdgMVMpUct4yg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dspace-community/CAKZKP2DDkUNJDExiOnGMiMMtWaM0PoZT3AcPtyBbd8LbBWpgWg%40mail.gmail.com > <https://groups.google.com/d/msgid/dspace-community/CAKZKP2DDkUNJDExiOnGMiMMtWaM0PoZT3AcPtyBbd8LbBWpgWg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-community/CAJP-v7CzGStO7s57YPRomn8oqaj-dh%3Dq3oz_Mm-My-QZqUihvQ%40mail.gmail.com.
