NOTE: Permissions apply across a whole database, irrespective of company.
User Access
The access that a user has to the system depends on the permission sets assigned to users on the IT user card. This is found under IT administration/ General.
NOTE: It is common practice to copy permission sets from one user to another.
Permission Sets
Here is an example of existing permission sets that have been created from Sparkrock standard permission sets and tweaked for a client’s specific needs. Permission sets have a code and a description, which indicates what access the permission set provides:
Permissions
To see what permissions are included in a permission set, highlight on the permission set and hit the permissions button indicated in the following example (double click does not work).
Permissions are mostly to do with access to table data:
Accessing table data has four possibilities – Read, insert, modify and delete. Typically, if a user attempts to do something for which they do not have permissions, the error message will describe the table and the action that is missing, e.g. ‘You do not have Modify permission to the Bank account’.
'Yes' and 'Indirect'
When creating permissions to Insert, Modify and Delete the permission can be:
- Blank – no permission
- Yes – may do this
- Indirect – a process invoked by the user may do this
The distinction between ‘Yes’ and ‘Indirect’ is not always clear, if in doubt use ‘Indirect’ and if the user gets an error then change to ‘Yes’.
Sparkrock Read Permission Methodology
In order to simplify the set-up and maintenance of permissions we have developed a methodology that works for most of our clients. We do not include read permissions on the general permission sets, but instead have separate read permissions. Where users may read all tables (though of course not insert, modify or delete) we assign a permission to those users of ‘Read all’.
Here a wild card is used – object ID is set as 0. This gives read permissions to all users:
However, where users are to be filtered from certain dimension values or where confidentiality is to be protected on certain tables, then additional read roles are required to be created. These will list the tables that the user has access to and add in security filters if required.
Security Filters
These can be a little tricky to set-up and maintain, hence it is recommended to minimize the use of security filters. Too many security filters and maintenance and assignment of permissions becomes difficult. The simplest way to use security filters is to only use them on the read permissions.
In the above example, the G/L entry table (general ledger entries) has a read restriction on Global dimension 1, which is the ‘Fund’ dimension. So, if a user gets this read permission they will only see entries that are for funds 115, 155, T190, T192 and T193. Hence if additional Funds are added and users that have this permission are required to see those additional funds, then this security filter will need to be amended.
NOTES:
- Security filters could be imposed on more than one table.
- There is a limit to the space available to add filters.
'Basic All' Permission
This permission is slightly different in nature from the others in that it includes permissions to using other objects as well as table data.
Unless a user has the ‘basic all’ permission they will not be able to log into the system at all.
The permission set includes permission to tables that are required for logging in, permissions that are common, and buffer tables used in the background. As mentioned, it also includes permissions to enable the use of other objects – mostly with wild cards.
'Super' User
Super user permissions enable a user to do anything in the system including log deletion, changing permissions and setting up users. It is required to have super users, but these should be limited as far as possible and restricted to IT department. Operational users should not be super users.
.
Company Filters
Permission sets can be assigned to users that are specific to companies, as in the following example:
Thus, a user could have different roles in different companies. Assigning super user to a user in any company is not recommended as that user can then still amend permissions.
User Groups
Where groups of users have identical or similar permission sets, these can be grouped into user groups and user group permissions assigned. One or more user groups may be assigned to users. Users then inherit the user group permissions
NOTES:
- A user can belong to various user groups and have their own permissions in addition.
- Additional permission sets cannot restrict a user, only add to permissions