Managing rights for the application

After an application has been deployed, you must define rights for all user groups that you want to have access to the application.

For an application with an approval hierarchy, each node in your approval hierarchy has rights assigned to the user groups that exist on the server that hosts your application. The rights that you assign determine the actions that can be performed by members of the user groups.

For applications without an approval hierarchy, you can assign a group to have full access to the application. Central apps can be designed to either allow users to take ownership or only to edit nodes.

Assigning rights for an approver

In a typical application, an approver is assigned either Review or Submit access rights at consolidation nodes in the approval hierarchy. As an application designer, consider the following extra questions:
  • Is the approver required to see all levels following the designated consolidation?

    If yes, you can control how many hierarchy levels that the user sees by using the Review Depth and View Depth options in the Add Rights window.

  • Is the approver required to edit leaf nodes or just submit or reject them?

    If yes, you can allow an approver to edit leaf nodes by enabling the Allow Reviewer Edit option in the Rights window.

When you assign rights for a consolidated node, those rights are applied to all the descendant nodes of that consolidated node. Descendant nodes include consolidated and leaf nodes under the consolidated node. Cascading rights assignments have the following behavior that depends on which access right you apply to the initial consolidated node:

The Allow Reviewer Edit option and the Review Depth and View Depth options in the Add Rights window overrides the cascading of Review and Submit rights on a consolidated node as follows:

Assigning rights for a non-approver

To provide a non-approver user or contributor the ability to perform multi-node editing, you must assign at least View rights to the consolidated node. This minimum rights assignment makes the consolidated node the starting point from which the user can access, edit, and submit all descendant nodes to which they have the rights. Users must take ownership at the consolidated node to use the Multi-Node Edit ability to gain access to all the related leaf nodes. As an application designer, you must consider the following additional questions:
  1. Does the non-approver require the ability to update more than one node at a time with the Multi-Node Edit?

    If yes, consider question 2.

    If no, you can either assign Edit or Submit rights to individual leaf nodes for the non-approver.

  2. Does the non-approving user need Submit rights to all nodes reporting to a parent consolidated node?

    If yes, consider question 3.

    If no, assign Submit rights to the designated child nodes.

    Note: When you assign Submit rights to a leaf node, the underlying TM1 security cube also allows Write access to the consolidated parent of the leaf node. This ensures that values can be spread from the consolidated parent to the leaf nodes for which the user has Submit rights.
  3. Is the non-approving user responsible for submitting the consolidated node?

    If yes, assign Submit rights to the non-approver at the consolidation node.

    If no, consider question 4.

  4. Is another user responsible for submitting the consolidated node?

    If yes, assign Review rights to the non-approver at the consolidation node.