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 On Wed, Apr 17, 2024 at 8:52 PM Kimberly Chapman < [email protected]> wrote: > 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/CAKZKP2Cma_2WRb0zbt9vQyVTg%3D4taEzp2ySXBvE1-JyDHmqgFg%40mail.gmail.com.
