0 Soliciting input on Group rights... what is everyone else doing? 2 Jim Michael posted 8 Years Ago I am trying to determine how others are handling security rights on serving groups. I’ve come across an architectural stumbling block with the way group rights are inherited, which is now making me wonder if WE’RE “doing it wrong” since I haven’t seen anyone else complain about this behavior. First, a simple explanation of what we’re wanting to do. This is a hierarchy of Group Type = Serving Team: What we were planning is to have all serving teams be of the same Group Type, but then restrict which roles can edit which top-level parent groups (and their children). So all staff would be able to VIEW all Serving Teams, but only people who need to would be able to edit teams in their areas, via separate roles for each parent group. Simple (I thought). The problems occur when I added Edit rights to (for example) the Churchwide group to role1, which works fine… but children beneath Churchwide do NOT inherit their parents’ rights… at least not in the right order! This is what I see on a CHILD of a parent that has been given edit rights: As you can see, the child group IS inheriting the parent’s rights from the Churchwide group, but these are BELOW the “All users deny” that gets inherited from Global Default, making them ineffective. I’ve been told the order of rights on a group is: check the group itself, then check the group type, then check the parent group… which is why we see this order of inheritance here. (As an aside, I’m not convinced this is the correct order and don't know if it was made arbitrarily or for specific architectural reasons, but to me the proper order of inheritance should be group itself, parent group, group type… which if it were in place would solve this problem.) Anyway, back to my issue… clearly touching and managing the rights for every individual child group doesn’t make sense, so this is why I’m soliciting other Rock users to see what they’re doing. I’ve come up with a couple of potential solutions here, but not sure either is desirable... Use different Group Types for all of my Top-Level serving teams, then assign edit rights at the Group Type. This is simple, but I don’t like the idea of having separate Group Types for all of these parent teams just to facilitate rights management when the groups themselves are really all of the same type (Serving Team). At the Serving Team Group Type, assign edit rights for ALL top-level Serving Team roles, then within each top-level Serving Team, DENY rights for the "other" Serving Teams… this would have the desired effect of restricting edit rights at each parent to a specific role, and keep all groups under one Group Type, but seems pretty kludgy and a maintenance nightmare over time. Something else? Do most of you just let all staff edit any Serving Team, and thus aren’t bumping into these issues? How is everyone else handling this? Am I way off the reservation here? All feedback welcome!
Jim Michael 8 years ago Thanks for the sanity check, David. It looks like #2 is a non-starter, even if I wanted to go that direction... I went ahead and tried a proof of concept with it and it has the same problem that started this thread... rights assigned at the Group Type short-circuit any explicit rights that flow down from a parent group, which makes sense had I thought about it in more detail. Anyway, there seems to be no solution for inherited group rights other than multiple group types.