...
- Similar to COUs, membership in a parent Group will not automatically imply membership in any child Group.
- 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.- Slashes (and colons) could be replaced on a per-Provisioning Target basis using a Data Filter.
- 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 ofLunch Societies
, the full name of the Group will beLunch Societies/Pizza Aficionados
. There will be no leading slash so that flat Group structures are not affected.- 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.
- Only CO Administrators can set or change a parent Group ID . Because because this will effectively result in the Group being renamed.
- The Self Service widget might offer more flexibility.
- Group Nestings will continue to operate as is, with no direct relation to Group hierarchies.
- 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.
- Similarly, Owners Groups can not be given parents or children.
- 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).- 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 toLunch Societies/Pizza Aficionados
). - Alternately, Owners Groups could potentially be named based on the Group ID rather than the name, eg
CO:owners:275
.- Owners Groups would be accessed only via the related Group.
- The Group Index would not show Owners Groups at all.
- Global Search would skip Owners Groups.
- The unique name constraint might be too limiting, in which case the base Group name would need to be eg
Summary of Related Concepts
...