View Authorisations

View authorisations can be set up so that different groups of users only see the data objects relevant to them when using ActiveControl. For example, if you have completely different teams delivering projects and/or performing Production support activities, each team member only sees the transport paths, transports and configuration relevant to their area.

The main concept in view authorisations is the Authorisation Group. An Authorisation Group can be allocated to each ActiveControl object (Path, Project, Group etc.). Each user is then allocated a SAP Role giving them access to certain Authorisation Groups. A user will therefore only see the objects allocated to an Authorisation Group they have access to.

Authorisation Groups can be assigned to the following Objects in ActiveControl:

• Paths – If there are multiple teams, such as Production Support and Project teams, each team member only sees the transport paths relevant to them. So a Production support team member would only see the Production Support paths in ActiveControl and could only allocate a transport to those paths
• Projects – Different teams may only be able to allocate Tasks to certain projects
• Groups – The valid Groups can be restricted on Tasks and Transport forms
• Types – The valid Types can be restricted on the Tasks and Transport Forms
• Change Paths – The change paths can be restricted when creating Tasks
• User Roles – The user roles can be restricted when creating Tasks
• Custom Fields – Whether a custom field is visible to a user
• Import Methods – Import methods available can be restricted

Currently, all View Authorisations configuration is done in the SAPGUI.

Note: If an object (Path, Project, etc.) is not allocated to any Authorisation Group, all users will have view access to it by default so if this is not required please ensure that all object values are allocated to at least one authorisation group.

• Authorisation groups can be maintained in table /BTI/TE_AUTHGRPS.
• To allocate an Authorisation Group to a ActiveControl object an entry needs to be maintained in the table /BTI/TE_AUTHOBJS on the domain controller.
  

Table fields for /BTI/TE_AUTHOBJS

Once entries in the authorisation objects table have been maintained, roles will need to be created and allocated to users so that ActiveControl can determine which authorisation groups each user has access to. The authorisation object that controls this access is Y_TEAUTH_V.

Authorisation Object Y_TEAUTH_V fields.

Once the required roles for View Authorisations have been created, they should be allocated to the appropriate users.

Important Restrictions Regarding View Authorisations

! It should be noted that although View Authorisations allow for a very granular way of restricting the objects that are displayed to users when they log into ActiveControl, the complexity and ongoing overhead of the role and user maintenance should be taken into account.

It is also important to understand that assigning Authorisation Groups can have unintended consequences if not all objects within the object hierarchy are allocated to the same set of groups. For example, the View Authorisations configuration may give a user access to see a particular path, but not access to see Tasks (or Forms) that are part of a particular Project. This means the user will not be aware of all of the transports waiting for approval in a control point, but only those they have authorisation to see. They could therefore inadvertently only approve the transports they have authorisation to see, without knowing the full picture.

In general it is only recommended to use View Authorisations to separate out ActiveControl objects at the highest level, for example, to give separate views to the project delivery and production support teams, or to give separate views to two completely separate project teams using the same ActiveControl Domain Controller.