COmanage Groups are primary Registry objects, and are defined at the CO level. Group Memberships attach at the Person level, although they may be created from Person Roles and other sources via various mechanisms.
Broadly, there are two categories of Groups: Standard Groups and System Groups. System Groups have various special characteristics, and include Automatic Groups, Admin Groups, and Owners Groups (described below).
Standard Groups may not be named beginning with the prefix |
An open group is one that allows anyone to join. Participants can self-join, no administrator action is required. Memberships in a closed group can only be set by the group owner.
In addition, CO Administrators can manage any Group within their CO.
Automatic Groups are those which Registry automatically manages the memberships of. Registry manages Automatic Groups for all members and all active members of each CO and each COU. See Special Groups, below, for more information.
Identifiers can be attached to Groups, either manually or via Identifier Assignment.
Identifiers cannot be assigned to Automatic CO Groups. (CO-1829) |
A Group Owner has permission to add and remove Group Members to and from the Group, including closed Groups. A Person need not be a Member of a Group to be an Owner (though they do need to be a Member of the Owners Group).
Admin Groups are used to determine Registry Administrators. Admin Groups are automatically created when a CO or COU is created. The Platform Administrator typically sets the initial CO Administrator.
GroupEnum::Admins
and a null cou_id
. The default name for the group is CO:admins
.GroupEnum::Admins
and a non-null cou_id
. The default name for COU admin groups is CO:COU:COU_Name:admins
.Members Groups are automatic groups that are updated with all members of the CO or COU. Members Groups are automatically created and updated, and cannot be manually manipulated.
GroupEnum::ActiveMembers
and a null cou_id
. The default name for the group is CO:members:active
.GroupEnum::AllMembers
and a null cou_id
. The default name for the group is CO:members:all
.GroupEnum::ActiveMembers
and a non-null cou_id
. The default name for the group is CO:COU:COU_Name:members:active
.GroupEnum::AllMembers
and a non-null cou_id
. The default name for the group is CO:COU:COU_Name:members:all
.When a new Group is created, a corresponding Owners Group is also created. The Group Owners (as described above) for the new Group are managed by adding the designated People to the Owners Group. (If the Person who created the new Group is not an administrator, that Person will automatically be added to the Owners Group; AR-Group-7) While Owners Groups are implemented using the same Group infrastructure as Standard Groups, there are several restrictions on Owners Groups:
It general, Owners Groups should be treated as "black box" functionality within Registry, and should not be provisioned to or otherwise integrated with external systems. Note that Group Nestings are supported for Owners Groups, so that a single Group can be used as a Standard Group (and therefore be provisioned) and also to populate an Owners Group.
Note that non-administrator access to Group Management functionality requires the use of the Group Dashboard Widget (CFM-316).
Section not yet updated.
Group Memberships can be added as part of an Enrollment Flow by adding an attribute of the appropriate type. For more details, see Registry Enrollment Flow Configuration.
Group Memberships can also be added via Organizational Identity Sources when connected to Pipelines.
Group Nestings allow the Members of one Group (the "nested" or source Group) to be automatically included as Members of another Group (the "target" Group). Group Nestings only confer membership, they cannot be used to manage ownership.
Currently, only CO administrators can create or remove nestings.
Nested Groups do not imply any sort of hierarchy (CO-1223).
It is possible to apply boolean operators to Group Nestings. The configuration takes place in two places:
Group Memberships can have Valid From and Valid Through dates attached. See Registry Validity Dates for more information.
Group Nestings honor validity dates. If a Membership is not yet valid or has expired, it will not propagate to the Target Group. When a Group Member validity date takes effect, Group Nesting changes will not automatically happen. The ValidateGroupMember job must be used to process these changes.
In general, nested Group Memberships and Memberships of automatic Groups are updated in real time as needed. However, If an automatic Group or a Group with Group Nestings appears to have incorrect Group Memberships, the Group may be manually reconciled to fix incorrect memberships. To reconcile a Group, find the desired Group and click Reconcile.
Manually reconciling a Group will not automatically reconcile related Groups. For example, if Group A has nested Group B which in turn has nested Group C, and Group C is manually reconciled, it will probably also be necessary manually reconcile Group B.