The user is allocated for the group by the administrator. If the administrator wants to add the user to the group, first he has to check that the user can be really assigned to this group - checking that the group can cooperate with the groups which are currently defined for this user. This process is done automatically on the basis of the group constraints. The group constraints qualify which groups can not be used in the same time by the one user. They are stored in the separate table in the database (see section 1.13, figure 1.8: AR_Group_Constraints).
The fields group1_id and group2_id in the table are foreign keys to the table groups (Table 1.3). The algorithm, which veryfies the groups, takes from the user the current list of his groups (from table 1.2). The values from the list are set together one by one with the id of the new group which we want to add. Each couple of values is used as a condition for the WHERE clause in the following SQL statement:
For each couple of groups one SELECT is executed. When all combination of groups are positively verified (no results for each combination) then the user can be appraised to the group. If there is a result then this means that the constraints are defined for this combination and the new role group can not be added to the current set of groups defined for the user. The algorithm is not stooped in this point and it just go through the all combinations. All results are collected and then they are showed to the administrator. The administrator has clear picture which groups are in the conflict with the new group.
The constraints for the groups are optional and it should be defined only if they are needful (the decision stay with the administrator). In the section 1.9 you can read how the constraints are defined.