Overview
As a collaboration grows in size, it may be useful to create various structures to allow for delegation of person management operations and representation of organizational hierarchy. COmanage Registry supports this through the concept of CO Units, or COUs. As of Registry v3.1.0, CO Departments are also supported.
Collaborative Organizational Units (COUs)
COUs have a hierarchical relationship within a CO, much in the same way LDAP OUs have a hierarchical relationship within an O.
COUs are a structural object within Registry, meaning they can be configured, and that they are used internally for a variety of purposes. The primary purpose of a COU, however, is to allow for delegation of person management operations. COU Administrators can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU).
If COUs are defined, they can be flat (no hierarchy, all are at the same level), or a COU can have a parent COU (in which case a hierarchy is implied).
Prior to Registry v3.3.0, if COUs are defined all CO Person Roles are required to be associated with a COU. (Existing CO Person Roles are not assigned COUs if COUs are enabled after they are created; CO-322.) As of Registry v3.3.0, this behavior is configurable via Configuration > CO Settings > Enable Empty COUs. If enabled, it is possible to create a CO Person Role that is not associated with any COU. COU Administrators will be unable to edit the attributes associated with that CO Person Role.
CO Departments
CO Departments are primary objects within Registry, which means that they are intended to store representations of external objects (just like CO People). CO Departments can attach to either a CO or a COU, and can be used to store a number of attributes about the department, including telephone numbers, email addresses, URLs, identifiers, and the sets of people associated with specific responsibilities within the department. CO Departments can be used to support various use cases:
- In a VO deployment, CO Departments can be used to represent research groups.
- In an enterprise deployment, CO Departments can be used to represent the University department hierarchy.
While there may typically be a one-to-one relationship between CO Departments and COUs, it is not strictly necessary. For example, a COU maybe made up of members spanning two departments.
CO Departments are visible to anyone within the CO, by logging in to Registry, though only CO Administrators may edit their information.
CO Departments are specifically intended to be used with Registry Services and the Service Portal.
COUs vs CO Groups
- Any CO Person can create a CO Group; only CO Administrators can create COUs.
- CO Group Memberships attach at the CO Person level, whereas COU memberships attach at the CO Person Role level.
- Management of CO Group Memberships is simple (e.g., manual management by the CO Group Owner, self-opt in for open CO Groups, etc.), whereas COU memberships can be managed using Enrollment Flows and Expiration Policies.
- COU memberships imply CO Group Memberships (in the Members:COU group).
- Email Addresses can be attached to CO Groups via CO Email Lists.
Comparison Summary
| COU | CO Department | CO Group | |
|---|---|---|---|
| Object Type | Structural Object | Primary Registry Object | Primary Registry Object |
| Belongs To |
|
|
|
| Has Many |
|
| |
| HIerarchical | Yes | No (CO-1523) | No (CO-721) |
| Supported Attributes | None |
|
|