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 created by specifying the RestrictedOrg when calling the saveContainer function.

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

  • getOrgModel - This function returns only those organizations to which the calling user has access because of organization relationships.
  • listCandidateResources - This function 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 function 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 function is used to map users to positions in an organization.
    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.

  • All resources can see Org1 and LDAP1 because neither has an explicit relationship set up.
  • The resources in containers that have an organization relationship can also see the LDAP container they are in, as well as the organizations for which their container has a relationship.
  • Any of the resources can be mapped to Org1, as well as to the organization(s) to which their container has a relationship.

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.

Note: If a resource has been mapped to a position, then an organization relationship is set up that would bar that resource from membership to that position, it results in an invalid membership. Resources that have been mapped to invalid memberships should be removed (the updateResource function can be used to remove memberships).