It is possible to assign the group access permissions by reference to other groups. A field on Groups allows you to list subgroups for the group. This means you can create "building blocks" of access permissions (at the subgroup level), that can be combined to create an "access profile" for a main group. This effectively allows you to set up a main group as a job role or "model user". You then assign each user to a main group. The content of the role is independent of the users assigned to it and you can change it without mass changes to the users.
📌Note: It is possible to assign users to more than one group. However the intention if using the main group/subgroup approach is to have a separate group for each job role. This may be more appropriate for large organizations with clearly defined job roles.
For example you might create a main group AP Clerk that is assigned access from two subgroups: AP Input and AP inquiry. You can set the access permissions for the AP Clerk group by setting the access permissions for AP Input and PL inquiry and setting the AP Clerk group to inherit access from these two subgroups.
When you have set up the subgroups, you need to run a process to set the access on the main group. This process evaluates the subgroups in turn (much like the group access is evaluated on a user); as soon as a Y-Allow or N-Deny is found in the subgroups assigned, the Y or N is set on the main group being evaluated.
This is equivalent to compiling the subgroup access to create the main group access. (You could then modify the main group but we do not recommend this since, if you were to re-run the process, the main group access would again be overwritten by the evaluated subgroup access.)
📌Note: If you change the permissions on a subgroup or change the list of subgroups on the main group, the changes will not apply to the main group until you re-run the process.
You can then assign user access by setting the groups on the user. Either main groups or sub groups can be used for this.
If a sub group access is changed, the main group access can be re processed; you do not need to modify the main groups themselves.
Coins ERP+ only evaluates one level of sub groups during the process; it is not recursive down to further levels of sub group. (If you choose to build a set of groups from a set of sub groups you could then use the evaluated groups as sub groups to further groups by processing them in order.)
Prime Group
The Prime Group (specified on a user's record) has implications for data security: combined with the user's security level it allows access to other users' batches and reports. We recommend that you use one set of groups for access to data, and a separate set of groups for function security.
Other Uses of Groups
Groups are also used for Group Field Security and for HS Sales Event Security. The process of evaluating the group function access also applies these two security models.
The process of evaluating these is similar. The sub groups are processed in turn and the first one that contains a sub group security setting (for fields or sales events) is copied to the equivalent main group setting as though it had been built manually by the user.