In Registry v4, CO Groups are flat. While naming conventions can be used to represent a hierarchy of sorts, this implicit hierarchy has no semantic implications for Registry. COUs do have a hierarchy, and since COU memberships imply automatic Group memberships it is important to coordinate the behavior between COU and Group hierarchies.

Proposal

Group hierarchy will be implemented using the same Tree Behavior as COU hierarchies, which implies parent_id, lft, and rght foreign keys. Group hierarchies are intended to allow for

  1. Establishing a hierarchical name space.
  2. Permit restrictions on self service group management, for example to limit open Group creation to within a certain leaf. Self service management will only be available via Dashboards.
  3. Cascade permissions. Similar to COUs, ownership of a Group will permit management of any child Group.

Additional Characteristics

  1. Similar to COUs, membership in a parent Group will not automatically imply membership in any child Group.
  2. Because colons (:) are already used to denote special Groups, slashes (/) will be used to denote hierarchy. Neither colons nor slashes will be permitted in Group names.
    1. Slashes (and colons) could be replaced on a per-Provisioning Target basis using a Data Filter.
  3. The full name of the Group (eg: as provisioned) will be constructed using any parent Groups. For example, if Pizza Aficionados is a child group of Lunch Societies, the full name of the Group will be Lunch Societies/Pizza Aficionados. There will be no leading slash so that flat Group structures are not affected.
    1. Note that because Group names must be unique within the CO (see below) it's not actually a requirement that Group names include the leading portion of the hierarchy. This could potentially be configured, either via CO Settings or per Provisioning Target.
  4. Only CO Administrators can set or change a parent Group ID because this will effectively result in the Group being renamed.
    1. The Self Service widget might offer more flexibility.
  5. Group Nestings will continue to operate as is, with no direct relation to Group hierarchies.
  6. In order to avoid unnecessary complications, moving a COU within the COU hierarchy will not move the corresponding automatic Group. Automatic Groups will remain in a flat name space.
  7. Similarly, Owners Groups can not be given parents or children.
  8. Owners Groups names will use the base Group name only, eg CO:owners:Pizza Aficionados. As such, Group names must continue to be unique within the CO (not just within the leaf).
    1. The unique name constraint might be too limiting, in which case the base Group name would need to be eg CO:owners:Lunch Societies/Pizza Aficionados, Alternately, perhaps a Data Filter could rename "duplicate" group names (eg: Lunch Societies/Lunch Pizza Aficionados gets renamed at the Provisioning Target to Lunch Societies/Pizza Aficionados).
    2. Alternately, Owners Groups could potentially be named based on the Group ID rather than the name, eg CO:owners:275.
      1. Owners Groups would be accessed only via the related Group.
      2. The Group Index would not show Owners Groups at all.
      3. Global Search would skip Owners Groups.

Summary of Related Concepts


Applies ToAffects MembershipsCascades PermissionsEnforces Namespace
COU HierarchyPersonRole
(tick)
Group HierarchyGroupMember
(tick)(tick)
Group NestingGroupMember(tick)

See Also

  • No labels