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.
