Role Permissions

Permissions are an additional layer of control over what your Users can see or do with objects, and the Role permission type is the most efficient way to control permissions in dynamic systems. As Users become associated to objects, their permissions on those objects, will match the Role they have on that object, or any other object with those permissions applied.

Roles are set up by you, as a part of your system model. As you develop your model you may decide that users who are associated to an object, should have permission to do something to that, or an associated object.

To do this, you must first set the Association type concerned to be a "Role" and then set the object type to be a Permissions Control Container.

This Help Resource demonstrates how to configure an Association Type to be a Role and then uses that Association Type in a working system to demonstrate the purpose of "Role" Association Types.

Setting An Association Type to be a Role

Log into System Modeller and click the "Search Page" tool. Then, select "Association Types Manager".

Find and open the Association type you want to set as a Role permission, in this example, "My Job Applications" and tick the Is Role Option.

Save and Close will return you to the Association Types Manager screen, where you will now see the Association Type coloured in gold, indicating clearly that this is now a Role association type.;

In this example we want people who have created an Application for a job to have the ability to edit it. i.e. anybody who is associated to a job Application with the association "My Job Application", will be able to edit it.

So the Application itself has to be configured to be a "Permissions Control Container".

Setting an Object Type to be a Permission Control Container

To better understand what a "permissions control container" is, we should first understand that the usual "Permission Control Container" is the standard object type Group. As you will know, Users who are contained in a Group will have the permissions granted to the Group.

So, this is how Groups work - the permissions control container is the GROUP and the role association is "CONTAINED BY".

If we now return to our job Application example, the candidates who make the job Application are associated to it as My Job Application. The job Application has been configured as the permission control container, and the association My Job Application has been set up as the Role.

We can now use this role association to configure Permissions. In this example, we are going to restrict the Read access to a web page to only those people who have made a job Application.

Edit the web page object and go to its Permissions tab;

Currently the web page has been configured for General Public to Read.

We definitely don't want General Public to be able to read this page. Only logged in users. In fact we only want users who have made a job Application to be able to see it.

So we will remove the General Public permission group and add in a Role permission, specifically for job Applicants.

Click the Role to open this form;

Select the required permissions control container (Application);

Select the Association (role);

And then select the base container, inside which you want all of these Roles to work (in this example it is a Group called "Job Goblin");

So we have now set a Role Permission on the web page, for anybody who is inside the Job Goblin group - anywhere at all - who has an association "My Job Applications" to an "Application"