Organization Relationships

When you are creating or editing an LDAP container, you can specify that the LDAP container have a relationship with one or more organizations.

These organization relationships allow you to prevent users from seeing LDAP containers and organizations they are not intended to see, as well as prevent resources from being mapped to positions in organizations they should not be in.

Organization relationships are specified using the administered-organisation element when calling the saveContainer operation.

When an organization relationship is set up, it can affect the response from the following operations (unless the caller has a system action that overrides organization relationships — see Overriding Organization Relationships):

• getOrgModel - This operation returns only those organizations to which the calling user has access because of organization relationships.
• listCandidateResources - This operation returns an empty response if the calling user does not have access to an organization to which an LDAP container is associated because of organization relationships.
• listContainers - This operation returns only the LDAP container in which the caller was created, as well as LDAP containers that have no organization relationships set up.
• updateResource - This operation is used to map users to positions in an organization. It will only allow you to map resources to organizations allowed according to any organization relationships that have been set up. (This cannot be overridden by a system action; if a resource is barred from being mapped to an organization because of an organization relationship, you cannot map that resource to the organization regardless which system actions you possess.)
  Note: Organization relationships do not apply to groups, as they are separate from, and outside, the organization structure of the organization model.

The following summarizes the result of organization relationships (these descriptions assume the calling resource does not have a system action that overrides organization relationships):

• Resources that are in a container that does not have a relationship with any organization can:
  • see containers that do not have a relationship with any organization.
  • see organizations that do not have a relationship with any container.
  • be mapped only to organizations that do not have a relationship with any container.
• Resources that are in a container that has one or more organization relationships can:
  • see containers that do not have a relationship with any organization, as well as the container they are in.
  • see organizations that do not have a relationship with any container, as well as organizations to which their container has a relationship.
  • be mapped to organizations that do not have a relationship with any container, as well as to the organizations that have a relationship with the container the resource is in.

The following graphic illustrates these points by showing four organizations and four LDAP containers. The arrows represent a relationship between the container and the organization. Under each container is a resource that is in that container, and to the right of each resource is shown the organizations and LDAP containers the resource can see.

An important point to understand here is that if multiple containers have a relationship with a single organization, the resources in one container will not be able to see the resources from the other container when viewing the organization to which they both have a relationship.

For example, using the illustration above, if a resource from both LDAP3 and LDAP4 are mapped to the same position in Org3, when a resource from LDAP3 looks at that position (using the Organization Browser, when creating supervised work views, or when allocating work items to world), that resource will not see the LDAP4 resource that is mapped to that position. Likewise, a resource from LDAP4 will not see the LDAP3 resource when looking at that position.