GAM Permissions can be grouped in hierarchies in order to ease the management of them.
The definition of permissions can be done using a hierarchical structure, so as the maintenance is much easier.
In this hierarchy there are children and parent permissions (it´s a tree structure), and while children inherit the behavior from their parent, any change in the parent is reflected in the children.
Given a permission, how do I define children permissions?#
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.
So in order to define a child for a permission:
- Execute the GAM Backend
- Go to WW Applications
- Edit the Permissions of the Application
- Find in the list the Permission which will be the "parent" Permission and click the icon shown in the figure below in order to define its children:
Figure 1. Given "ParentPermission" permission, we add children by clicking on the image shown.#
Then click "Add Children" button and select the permissions which will be children of the parent permission.
Figure 2. Click Add Children button to select and add the children permissions#
Note that the Default Permission Access Type of the children will be the same as the parent. So if you specify that the parent has "Restricted" Default Access Type, the same will apply for the children.
What happens when a "Parent" permission is associated to a Role?#
When a "parent" permission is associated to a Role all the children permissions of this "parent" are expanded in the list of permissions of the Role.
Suppose in the following example that we add the permission "novels_fullcontrol" to a "parent" permission (note that "novels_fullcontrol" is in turn a parent permission wich has novels_execute, novels_update, novels_delete, novels_insert), as seen in figure 3:
Figure 3. Add "novels_fullcontrol" as child of "parent" permission#
When you add the "parent" permission to a Role, you see all the permissions "children" expanded in the Role. For example, after associating the "parent" permission to "RoleSample" the permissions of the Role are the following:
Figure 4. Permissions of Role, after "ParentPermission" was associated to "SampleRole"#
What changes can be done in a permission?#
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.
Figure 5. Changes in Access Type of "parent" permission #
When is inheritance lost?#
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.
Figure 5. Permission loses inheritance#
Losing the 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 resides in the inheritance, so that the maintenance of several permissions is reduced to the maintenance of only one permission (which is the permission which "groups" the others). In fact, in execution time, the code checks for the children permissions, not the parent, which is only a fictitious permission used to group the others.
Case of Use#
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 as the management of all these permissions is reduced to managing only one permission.
Full Control Permissions and inheritance