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.
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.
We now add the Association Type to our Contact Object type, and create a rule to the "Company Organisation" object type;
Here it is complete, meaning it can be used in the XPOR administration page.
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
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;
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;
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.
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;
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.
This will add the new Permissions Role |Group to the Permissions table for the Company Organisations group;
Set the required permissions as normal, and recurse them to all Company Organisations;
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.