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
|OBJECT_TYPE||Object Type||This is the ActiveControl object type. Allowed types are in table /BTI/TE_AUTHOTYP. These table includes all of the objects that can be assigned to Authorisation Groups, including Paths, Projects, Groups, Types and custom fields|
|OBJECT_KEY||Internal ID|| The internal ID of the ActiveControl Object. This will be the numeric ID used as the object key in ActiveControl:
|AUTH_GROUP||Authorisation Group||The authorisation group that is to be associated with this object. The valid list of authorisation groups should be maintained in table /BTI/TE_AUTHGRPS|
|CUSTOMFIELD_VAL||Custom Field Value||(Reserved for future use)|
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.
|/BTI/TE_AG||Authorisation Group||This is the authorisation group (or groups) the user has access to. An * in this field indicates the user has access to ALL authorisation groups|
|/BTI/TE_C1||Path Category 1||A category can be allocated to a path. This could be to indicate all paths that are BW or XI, for example. And these entries can be used to allow access only to certain categories. The categories a user has access to should be put in this field. An * indicates the user has access to ALL categories.|
|/BTI/TE_C2||Path Category 2||(Reserved for future use)|
|/BTI/TE_TA||Target Dev System||This is the development system (or systems) for which the user is able to see transports without a Transport Form. This access restriction should only be required if there are multiple ‘source’ development systems. The SID of the development system(s) should be entered here. An * in this field indicates the user has access to all configured source systems.|
Once the required roles for View Authorisations have been created, they should be allocated to the appropriate users.
Important Restrictions Regarding View Authorisations
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.
Post your comment on this topic.