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 TE, the complexity and overhead of the role and user maintenance should be taken into account during the initial design phase.

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 TE 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 TE Domain Controller.


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment