GAM Permissions can be grouped in hierarchies to ease their management.
Also, permissions can be defined using a hierarchical structure to make their maintenance easier.
In this hierarchy, there are children and parent permissions (it's a tree structure); as children inherit the behavior from their parent, any change in the parent is reflected in the children.
Any permission (Automatic Permissions generated by GeneXus as well as Permissions Created by the User (X Evolution 3)) can have children.
Permissions exist within the scope of Applications, so that's where Permission hierarchies are going to be defined.
To define a child for a permission, do the following:
- Execute the GAM Backend
- Go to WW Applications
- Edit the Permissions of the Application
- Find in the list the Permission that will be the "parent" Permission, and click on the icon shown in the figure below to define its children:
Next, click on the "Add Children" button and select the permissions that will be children of the parent permission.
Note that the Default Permission Access Type of the children will be the same as that of the parent. So, if you specify that the parent has "Restricted" Default Access Type, the same will apply for the children.
When a "parent" permission is associated with a Role all the children permissions of this "parent" are expanded in the list of permissions of the Role.
In the following example, suppose that we add the permission "novels_fullcontrol" to a "parent" permission (note that "novels_fullcontrol" is, in turn, a parent permission that has novels_execute, novels_update, novels_delete, novels_insert), as seen in figure 3:
When you add the "parent" permission to a Role, you see all the "children" permissions expanded in the Role. For example, after associating the "parent" permission to "RoleSample", the permissions of the Role are as follows:
In the Role, you can change the Permission Access Type.
If you change the Access Type of the "parent", their children take the changes, unless the inheritance has been lost.
The following figure shows how a change in the Access Type of "parent" permission impacts in its children.
Inheritance is lost if the Access Type of a child is changed, or if the "Inherited" check box is changed.
For example, in the case above, if we change the Access Type of "novels_insert", this permission loses inheritance from its parent, and it's reflected in the "Inherited" check box.
Losing inheritance means that changes in the Access Type of the parent will not be reflected in the child.
Note: The real value of grouping permissions lies in the inheritance, so that the maintenance of several permissions is reduced to the maintenance of only one permission (the permission which "groups" the others). In fact, at execution time, the code checks for the children permissions, not the parent one, which is only a fictitious permission used to group the others.
Suppose you have the following GeneXus code:
Event "Generate Payments"
In this case, the permissions for executing ProcA, ProcB, and ProcC can be grouped in only one permission, so that the management of all these permissions is reduced to managing only one permission.
Full Control Permissions and inheritance