Role Management

Linked Help




If you associate to a Group as its' Leader, you will also have some permissions over the Group that the rest of the group won't have.  In other words you have a Role - you are associated to the Group as its' Leader and you have Leader permissions over the Group.

And if there are many Groups and many Leaders, using a "Role" is a quick way to set them all up in the same way!

In XPOR you can create an Association Type "Leader" and set it to be a ROLE.  This makes it available to the permissions control system to use as a Permissions Group set.


Roles are configured by setting an Association Type to be a "Role".  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 Object Modeller and navigate to the Tools tab and Association Type Manager. In the example below we have already created an Association Type called "Boss of".  It will be used to associate "Contacts" to a "Company Organisation" - as its' Boss(!).  Consequently the contacts who are associated to an organisation as "Boss of" must be able to view and edit its details.

Boss Association as a Role

We now add the Association Type to our Contact Object type, and create a rule to the "Company Organisation" object type;

Setting the Association Rule

Here it is complete, meaning it can be used in the XPOR administration page.

Boss Of available for use

So if we now log into the back end of the website and create a Company Organisation we can set its' Boss Of to be a selected Contact

 Association as Boss

In fact there are a lot of Company Organisations - inside a Folder.  Each Company Organisation has a Boss and we would like each Boss to be able to Edit his Organisation details.  We could achieve this in a number of ways;

  1. We could manually set individual permissions on each Company Organisation, for each individual Bossed By contact to have read / edit etc. permissions on the respective Company Organisation.  This would take a long time to set up and would make on going management very difficult.
  2. We could manually collect all Bossed By contacts into a new Group - called "Bosses".  We could then add this Group as a permissions set to the Group that contains the Company Organisations, set the required permissions and Inherit them to all child (Company Organisation) objects.  This would mean that each Boss could potentially edit any of the company’s.  So we would control this by providing a grid / query that goes from the logged in User ObjectID through its "Boss of" association type to access ONLY its respective Company Organisation.  This is quicker / easier to manage than the first option BUT means that when new organisations / bosses are added / removed, the Group containing the bosses needs to be edited accordingly.
  3. Use the fact that all Bosses have a Role Association to their organisation ...

Role associations can be used as a "virtual" permissions Group.  The big advantage is, that, whenever a a Boss is added or removed from a Company Organisation, the permissions are manged as a consequence.  So we will use Role Permissions. similar to the second Option above, and set them on the Group containing the Company Organisations.  We will then recurse those permissions onto all of the Child objects (Company Organisations).

First thing is to select our object to set its permissions - the Group called "Company Organisations" and select its' Permissions Tab.  Click the Add button and select the Role option;

The Role Permissions Option

This will open the usual Select Object, for you to browse and select the permissions Control Container that holds the things that you want to have permissions on this object.

In fact, in this example, you only need to select this group (itself) as it contains all of the Organisations and their associated "Bossed By" contacts.

Root for Role Permissions Selection


Having selected this Group object (which is a permissions Control Container) we now have to set the actual Role that we require to be used from this Container.  This opens a second form;

Describing the required Role to use


So, the first thing is to select an Object type - we are using the Company Organisation and want its "Bossed By" contacts to have the required permissions.  So we first select Company Organisation from the first drop down.  This will populate the second drop down with the Roles that are set on the Company Organisation object type.

Which Object Type and which Association is to be given permissions

This will add the new Permissions Role |Group to the Permissions table for the Company Organisations group;


The new Permissions Table entry

Set the required permissions as normal, and recurse them to all Company Organisations;


Recurse the Role Permissions


This will mean that any Contact that has the Role association "Boss Of" to a Company Organisation, will have the set permissions on ANY of the objects in this folder.  So, as with the second option, we will only allow the logged in user to see / edit his own "Boss of" Company Organisation by only listing this specific path on a front end form.

The huge management advantage of this is that when a boss is added / removed as Boss of any of the Company Organisations, the permissions work automatically.









 XPOR Ltd. UK Co. Registered in England No. 10409669
 02392 738000
 02392 739000