Overview

The COmanage Registry Data Model revolves around the Person, which conceptually represents one person associated with an organization.

• A COmanage installation is referred to as a Collaboration Management Platform, or CMP.
• A CMP is a multi-tenant installation, each tenant is referred to as a Collaborative Organization or CO.
• The core operational record of a participant within the CO is the Person.
  • The Person record maintains information that is unique to a person within the CO, such as names and identifiers.
  • An individual person should only have one Person record within a CO.
  • However, an individual person may participate in multiple COs housed within the same CMP, and could therefore have multiple Person records (each isolated from the other) within the CMP.
• A Person may have zero or more External Identities. An External Identity conceptually represents the Person's identity as asserted by a "home" or "external" institution, such as their University or a social identity provider.
• A CO Person may have one or more Person Roles within the CO. A Person Role record maintains information that is unique to a role a person has within a CO, such as title and physical address.

Tables

Registry is a database oriented application, with quite a few tables under the hood. These tables fall into a few broad categories:

• Primary Objects: Primary objects are those that directly relate to the primary purpose of Registry: storing information about people and other entities related to the organization. Example include People and Departments. Primary Objects can be identified because they belongTo Cos, and are not configuration objects.
• Secondary Objects: Secondary objects store additional information about Primary objects, in particular when there is a many-to-one relationship. Examples include Name and Email Address. Secondary Objects belongTo a Primary Object or another Secondary Object.
• Artifacts: Objects created in the management of Primary or Secondary objects. In general, Artifacts become read only once the process that creates them is completed.
• Configuration Objects: Configuration objects primarily relate to the behavior of the application.
• Metadata: Objects used internally by Registry.

Table Metadata

In addition to the column definitions available for each table below, all tables have additional columns used by the framework and supporting code. These columns include

• Timestamps managed by Cake (created, modified)
• Columns used in support of Changelog Behavior

Table Status

The statuses for each table are defined as

• Stable: The table definition will not change in a backwards-incompatible manner across minor releases. Stable tables may only be removed in major releases.
• Tentative: The table definition will likely become stable, but may change in a backwards-incompatible manner across minor and patch releases. Tentative tables may be refactored or removed without notice.
• Experimental: No specific assertion is made about the stability of the table. It may be changed significantly or even removed without notice.
• Obsolete: The table is no longer in use as of the specified version.
• Not Implemented: The table definition is for planning purposes only.

Major, minor, and patch releases are as defined in semantic versioning.

Table Inventory

Core Tables

Plugin Tables

Tables for Available Plugins will not be created until the Plugin is activated.