Hi, i’m looking for some tips fro setting up the following structure of security groups - bearing in mind that, as I understand it, the black no access between groups (as illustrated and where applicable) makes the groups easier rather than harder to configure.
I have looked around online:
Youtube videos are deliberately not comprehensive in an attempt to get people to pay for the courses that the broadcasters have set up.
I don’t understand the one and only guide, quoted multiple times across the web, that appears to have been started on the paid security group extension page and also why it says that it is necessary to start at the lowest, most restricted security group before working your way back up. For me, i’m still planning out structure so it helps me to work from the top, least restricted. Is this possible, and, if possible how so.
What I am struggling on most, specifically, is how groups can belong to other groups i.e. the top set should have access to everything and therefore would need to be a member of every other group.
Firstly, I agree with pgr, that you need a demo system setup that you can play with. I’m not sure what your resources are to get started… but I would start here if I didn’t want to set it up on my own machine: https://bitnami.com/stack/suitecrm
Secondly, I don’t use Security Groups, really, so I’m not sure I’m the best person to address this, but since you’re not getting any other answers… here goes…
- The true permissions, it appears to me, are set at the ‘role’ level. And ‘roles’ and ‘users’ can each independently be assigned to security groups. You may need to do both, especially if you want Security Groups to automatically be applied to records based on the Security Group the User is in.
- Because the rights are additive (this is selectable in settings), it is best to start with the most restrictive and work your way up. Let me give you an example, perhaps you have a Security Group called ‘City Cor 1’, of which all of the team members in the column are members of. They would also be in a role, say ‘Team Members’ (or whatever you bottom level role is). All of the accounts, for example, in City Cor 1, would be assigned to that Security Group. The duplicate everything I just said for City Cor 2-6 (or whatever). Now the ‘Role’ for the ‘Team Members’ would say that they can only see items for which they are the owner. The ‘Role’ for ‘Regional Manager’ would say that they can see items for which they are in the right group. And your NW Regional Manager would be added to City Cor 1-3. Your NE Regional Manager would still be in the ‘Regional Manager’ Role, but would be in City Cor 4-6 Security Groups. And so on. Your England SD, whatever that is, may have the same Role as the Regional Managers (or likely a different role, even if you don’t need it, so that you can change his/her permissions later… and he/she would be assigned to Security Groups City Cor 1-6. Your Executive Director may be in a Role that has access to everything, so his security group may not matter at all. Right now, the Direction and Strategy folks don’t have clearly different rights than the Sales Executive Director, so it is hard to know what to do with them. But you could just make two different roles (even if they are the same) and change them later.
Does this at least help to explain why it is easiest to think from the most restrictive up?
I would concur with the previous comments on what you are trying to achieve.
SuiteCRM’s security is very flexible, but that flexibility comes at the price of implementation complexity for many System Admins. Any security framework depends on having a COMPLETE picture BEFORE you begin to implement.
Definitely set up a test system, with at least one user at EVERY level in your organization’s hierarchy.
I do get a little wary when I see “to be added later” scenarios … it’s like you have not yet thought everything through, yet you still want the system to be flexible enough to accommodate your future needs … whatever they may be.
Generally, try to stay clear of paid SuiteCRM add-ons, if at all possible. Not only can they really run up cost, (especially if licenses are per-user and renewable annually) but they can also introduce problems when you upgrade SuiteCRM versions, in the future.