About groups, composite groups, and subgroups
Composite groups can be created to make the administration of authorizations and permissions of users easier and more efficient.
For example, you might have a user group that allows its member users to both read and execute Form A. A smaller subset of this group is also to be authorized to modify Form A.
You could create a group named AUsers for the larger group. You could then create another group named ADevelopers for the subset of users. By using the AUsers group as a composite group, you can then assign the ADevelopers as a subgroup of the AUsers group.
The result of this is that a member of the AUsers group would have only READ and EXECUTE privileges for Form A; while the ADevelopers would inherit all the privileges of the AUsers group, as well as the additional WRITE privileges.
Results of creating a composite group
When you create a composite group, any subgroups inherit the permissions of the parent group. However, the result of this is that both groups follow the rules given in the "How authorizations work together" section of the topic About users and groups. That is, the least restrictive permissions of either group prevail.
This means that if a parent (composite) group has Read-Only access of an object (form, IDO, or so on) and its child (subgroup) has Read-Write access, the end result would be Read-Write access for all members of that composite group. In order to get only Read-Only access, both parent and child would need to have Read-Only access.