When a user attempts to access a function:
Coins ERP+ checks the access permissions for the user (as set up in User Function Access). If the user has explicitly been allowed or denied access, this overrides any group permissions that may have been set up.
If you are using Menu Item Security, Coins ERP+ checks the parent function, which is an item on the Coins ERP+ menu, to see whether the user has access and the function is of the correct access type.
If the user has access to the parent, they have access to the child function by default, unless the permission has been explicitly overridden.
If the function is a menu, container or tab function, and the user has access to a function on that menu, container or tab, then the menu, container or tab is available.
If the user's permission is G-Group access (the default), Coins ERP+ checks the permissions for each group that the user belongs to, in the order the groups are defined on the user record, beginning with the Prime Group.
Coins ERP+ checks the can-do lists of functions and role types that are allowed or denied on the group. If the function is included in any of these lists, the user is allowed or denied access accordingly. (Within the same group, deny takes priority over allow.)
Coins ERP+ then looks at the permissions for specific functions set up on the group record. If the group is allowed or denied access then that is the result.
If you are using Menu Item Security, Coins ERP+ then checks the group access for the parent function; if the group is allowed access to the parent and the access type of the parent is the correct type, then the user is allowed access.
If the group record indicates G-Group access, Coins ERP+ checks the next group.
Because Coins ERP+ evaluates the permissions on each group in turn, the sequence of the groups on a user's record is important. If a group denies access to a function, the user will not be able to access the function, even if a later group would allow access.
Finally, if you have role-based licensing and your licence includes roles that are appropriate, you can use these to grant access to users. If the user is not a "named role" user Coins ERP+ checks any roles assigned to the user:
If the function is included in the "Allow" can-do lists of functions or role types on any of the roles, the user is allowed access unless explicitly denied by user or group access permissions.
If the function is denied by the role, Coins ERP+ continues by checking the user and group permissions. The user may still have access if allowed by user or group access permissions.
If the user is a "named role" user, they will ONLY be able to access functions allowed by their roles.
If none of the groups or roles explicitly allows access then the user is not allowed access.
When you create a new user record, all the permissions for that user are set to G-Group, so they only have access to those procedures and menus permitted for their group, until you explicitly change their access permission. Similarly, when you create a new group, all the permissions are G-Group. This means that, if you were to create a new group, and assign users to that group, without explicitly granting access permissions for either the group or the users, the users in that group would not be allowed access to anything.
Coins ERP+ always has a user called "SYSAdmin" and a group called "root". The SYSAdmin user has permission to do anything, as does any user who is in the root group who is not explicitly denied access.
Enquiring on function access
You can enquire on what access a user has to a function:
In Users, click the link in the User ID column.
Click the User Function Access tab.
Filter on the function you want to enquire about.
The Allowed column is ticked if the user has access to the function. The Access, Group and Role columns show whether the access or denial comes from the user function permissions, from a group, or from a role.
The following illustration shows how group access permissions affect the access of individual users. For a particular function, group A allows access, group B denies access, and group C specifies group access:
| User Function Access | First Group | Second Group | Role | Does the user have access? |
User 1 | N | Group A (Y) | Group C (G) |
| No |
User 2 | G | Group A (Y) | Group B (N) |
| Yes |
User 3 | G | Group B (N) | Group A (Y) |
| No |
User 4 | G | Group C (G) |
|
| No |
User 5 | G | Group C (G) |
| Role R (Y) | Yes |
If you are using Menu Item Security:
If a function is a menu, the user may be allowed access because they have been given access to a menu item on that menu.
If the function is a child, the user may be allowed access because they have been given access to the parent function.