Ownership

There are many cases where a business object or relationship might require multiple ownerships, such as a part that has multiple RDO, RMO, and RSO security attributes, each of which represent an organization or project owner.

You can specify multiple ownerships for an object. A complete ownership definition includes the following:

• Organization—a "role" object that represents an organization
• Project—a "role" object that represents a collaborative space
• Comment—a short string used primarily for annotation
• Access—a comma-separate list of security tokens

Each of these fields can be specified when providing an ownership. The first three fields (org, project, and comment) together provide a unique identifier for the ownership entry.

For the Project, you can assign a role that is defined as a user group (defined using asaprojectgroup as the kind of role). This type of role allows you to assign the user group as the extended ownership, and then allow the management of the user group to add and remove individuals as required. When a user group is specified for a PROJECT, the ORGANIZATION must be specified as '-'.

You can add ownerships to or subtract them from an existing business object or relationship. Ownership information is used to determine object access rights dynamically. Commands that are used to get or set the single organization/project ownership on business objects continue to function, but generate an error if more than one ownership is present.

For more information, see MQL Command Reference: Adding or Removing Business Object Ownerships and Adding or Removing Connection Ownerships.

Rather than maintaining security on a per-object basis, it is possible to govern a list of objects where the entire collection of objects has a common baseline access level by aggregating ownerships based on another object. This allows an object to inherit the ownership list from another object as its baseline access in addition to having its own direct ownership. Thus, it is no longer necessary to manage ownership by adding or subtracting ownerships individually on each object in a Bookmark Root since ownership for an object comprises an embedded reference to a parent object.

Existing applications that store parent information as a relationship (for example, Bookmark Root) must add an ownership definition in addition to the relationship. Applications that currently lack a parent or folder notation can create the parent ownership entry without creating a new relationship entity by specifying a parent object. The access rule engine dynamically extends an entity's ownership list to include the (non-inherited) ownerships of the parent.

To do this, you specify an object ID and another optional comment relating to the parent object. Ownerships, constructed in this form implement ownership inheritance from the parent. The access rule engine dynamically extends an entity's ownership list to include the ownerships of the parent. These inherited ownerships include all ownerships added to the entity using the multiple-ownership feature. The ownerships do not include the parent's primary ownership identified in the parent's organization and project basic properties. You can use ownership inheritance on multiple levels.