The TrackStudio Permissions model

1. The TrackStudio Permissions model

2. Introducing the permissions model • TrackStudio has a powerful and sophisticated permissions model • This model allows TrackStudio to be configured so that: • Users only see the Tasks (projects) and Users to which they are granted access • Users are only able to process workflow state transitions that they are allowed to • Users can only see or modify the values of fields that they are allowed to • Users are able to access only functionality that is appropriate to their status • Users can get a consolidated view of all the Tasks assigned to them across many separate projects

3. What permissions mean in practice • TrackStudio can be made to be as simple or as sophisticated as you want. • The User’s interface is simplified so that he or she sees only items that are appropriate to his or her Status. • TrackStudio may be used, if desired, within the same organisation for many different task-tracking purposes and yet each User will see only Tasks to which they have been assigned. • Authority and administrative capability can be delegated. • Use of the same system for many purposes reduces the training and maintenance overhead.

4. Essential concepts • A User’s base or own Status • Granting Users access to Tasks • Ability to supplement or override own/base status within the context of a task • Categories define who is able to view, create, modify, delete or be initial handler for a task of that category • Within workflows it is possible to define who is able to view, process or be assigned as handler for any message type • Custom Fields have their own permissions

5. Base or Own Status • Each user within the TrackStudio system has a Base or Own Status • This status is displayed in the user’s profile:

6. Base Status availability • The Base Status that can be granted to a User is any Status that is available to the Superior who is either creating the User or editing his or her profile. • The availability of a Status is inherited; that is to say a Status is available to the Subordinates of the User who created it. • Any User with the right to create Statuses may do so. • The rights associated with a Status are defined by the person who creates the Status and may be edited by that person or a Superior.

7. Base Status rights • Base Status rights relate to: • Tasks • Users • Additionally each of these categories is broken down into: • Field-related permissions • Object-related permissions • Two types of field-related permission are available: • the right to View • the right to Modify • There are a number of Object-related permissions all of which determine thing that the user can “do”

8. Task field-related permissions • These can be seen on the User Overview page: And are edited under the Task Field Security tab

9. User field-related permissions • These can be seen on the User Overview page: And are edited under the User Field Security tab

10. Task object-related permissions • These can be seen on the User Overview page: And are edited under the User Security tab

11. User object-related permissions • These can be seen on the User Overview page: And are edited under the Task Security tab

12. Setting Task or User field-related permissions • Some permissions cannot be changed: Greyed-out permissions cannot be changed

13. Assigned Statuses within context of a Task • Within the context of a task a User’s base or own Status may be: • Left as it is • Supplemented by another status/es • Overridden by another status Stuart Manske has a base status of030 software developer but in this task he is acting as a tester Jesse Levon has two statuses in this task

14. Effective Statuses • The Status of users in the context of a task is confirmed by looking at the Effective Statuses page:

15. Behaviour of base Statuses • If a User, within the context of a Task, has multiple statuses, the rights conferred by each of the statuses are added together. • Status permissions take precedence over category, workflow or custom field permissions. For example: • If, within the context of a Task, a User’s Status or combination of Statuses, does not allow him or her to modify Custom Fields this is something he or she will not be able to do irrespective of the permission settings associated with any particular Custom Field.

16. Statuses in practice • Three types of Status can be thought of: • Statuses with rightsthat are to be assigned to users as an own/base status (you must have at least one of these; the Status administrator is available by default, its rights cannot be changed or the status removed). • Statuses with no rights (optional) - merely to be used as "labels" that can be given permissions in the context of Categories,Messages,and Custom Fields. • Statuses with rights that are to be assigned to users depending on their role within the context of a task (optional). These statuses are also used to identify who may do what in the context of Categories, Workflows and Custom Fields.

17. Status model option examples Simple Status Model where Statuses reflect role within the organisation Matrix Status Model where Statuses reflect role within any particular project

18. Connections to Tasks • The tasks a User can see are those at or below the point/s at which that User is connected to the Task Tree. • A User may be connected to the Task Tree at many different points. • Only the Superiors of a User are able to connect a User to a Task on the Task Tree. • To connect a User to a Task, log in as a Superior of that user who has access to that Task, select the Task and then go to:

19. Granting access to a Task • Go to the Assigned Statuses tab: • Click on the Grant access link: • Select either a Status or an individual User from the dropdown list: Selecting a Status will grant access to the Task to all Subordinates of the logged-in user who have that Status.

20. Users and Task Tree connections • In the as-installed DB different users are connected to the Task Tree at different points:

21. Users and Task Tree views • Each user sees only the Task to which he or she is connected and any of its sub-tasks: John Smith Charles Parmenter Chris Tuck Note that in the as-installed DB, of these, only User jsmith has the Navigation tree option in his profile set to “All tasks and users”: If a User has the right to edit his/her own profile (User Security), he/she may choose to change the view of the navigation tree but this will make the UI appear more complex.

22. Connections to other Users • By design a User that is able to create new Users (subordinates) is able to view and edit the profile of any of those users. • Additionally, either Users or their Superiors, if they have a Base Status that allows them to “create new access control rules for users”, may to allow others to view their profiles. • As with Tasks, access may be granted either to Users of a particular status or to individual Users. Again, as with Tasks, the Status or any individual may be supplemented or overridden.

23. Granting access to a User • Make the User to whom you wish to grant access the current user and select the “Access Control Rules” menu item: Grant access to either Users of a particular Status or to individuals: Supplement or override as desired.

24. Category creation permissions • When a Category is created, not only does that Category get associated with a Workflow, but various permissions relevant to it may be set. • To begin with you determine whether the Category has to have a handler when a Task of that Category is created and/or whether the Task may be assigned to group of Users:

25. Category-related permissions • Having created a Category that will subsequently become a node in the Task Tree you may wish to set the permissions related to that Task. • You may control the following aspects of the Task: • who may create a Task of that Category • who may view (be able to see) a Task of that Category • who may modify a Task (edit the Task itself and associated Task Custom Fields after it has been created) of that Category • who may be the handler of a Task of that Category • who may delete a Task of that Category

26. The Category permissions matrix • This is less daunting than it at first looks! • The dropdowns around the edge can be used to set a whole row, column or table to a particular value.

27. Understanding the permission matrix • In the page under the Category Permissions tab there is a matrix of Statuses and Permissions • The following is an explanation of how this works: Nobody of that Status has the Permission All of that Status have the Permission A User of that Status has the Permission if he/she is the Handler of the Task. A User of that Status has the Permission if he/she is the Submitter of the Task. A User of that Status has the Permission if he/she is the Handler or Submitter of the Task. Note that in the case of the “Can Create” and the “Can be Handler” permissions of a Category the terms Handler and Submitter refer to the Handler and Submitter of the PARENT task (the Task under which the new Task is being created).

28. Categories – the final step • Having created your Category, don’t forget to make it a sub-category of an existing Category. • See Slide How to create a Relation

29. The hierarchical Task Tree • The TrackStudio Task Tree is hierarchical and can be extended indefinitely. • However, so as to allow this you need to define what types of Tasks you want be be allowed to be created as sub-tasks of any particular type of Task. • An example of a real-world task tree is something like this:

30. Setting what Tasks can be sub-Tasks • To enforce that structure you would have to set the following rules: • only Projects can be sub-tasks of Programmes • …… • only Design tasks or Developer tasks may be sub-tasks of Modules • etc • This is done by creating Relations that determine which of the available Categories may be children of a Category • Note that this is the most frequently “missed” step in the configuration of Track Studio • Administrators create their Workflow, create a Category that uses that Workflow but then wonder why they cannot create a task of that Category

31. How to create a Relation • Ensure that you are at a point in the Task Tree that the Category for which you want to create a relation is available. • Select the Categories menu item from the Task menu: • Click on the Add a Subcategory link to display Categories available at that point in the Task Tree: Select the Category you want and click on the Add a Subcategory button.

32. Workflow message-related permissions • One of the functions of a Message may be to move a Task from one workflow-state to another. Messages may be created that don’t change a Task’s state. Another function of a Message may be to allow the Task to be assigned to a different Handler. • Irrespective of whether a Message changes a Task’s workflow-state or is used to change the Handler you may want to control who may: • View the Message (after it has been created) • be able to Process the Message (see this Message type in the Create a message view) • be assigned as the Handler of the Task (be visible in the list of available handlers when the Message is being composed.)

33. Workflow message permissions matrix • This works in exactly the same way as the Category permissions matrix. See slide Understanding the permission matrix

34. Custom Field related permissions • TrackStudio offers Custom Fields associated with: • Users • Tasks • Workflows • In the case of both User and Task Custom Fields it is possible who may: • View the field • Modify the field

35. Workflow custom fields • The Custom fields associated with a Task (a node on the Task Tree) are inherited by every sub-Task of that Task. • This is useful if all the Tasks in that branch of the tree have some shared attributes. • Sometimes though it is useful to have attributes that are not inherited. • If you want Custom fields for attributes that are not shared they should be created as Workflow Custom fields. • Workflow Custom fields are different in that they have a much more granular permissions model.

36. Workflow custom field permissions • In the as-installed DB the Product Lifecycle Workflow has Custom Fields. • Workflow Custom Fields have: • Permissions • Message Type Permissions For the Task>Edit page, not only is one able to specify what the Status the User has to have but one is also able to specify the State that the task needs to be in for the field to be viewed or its value modified. One is able to specify in what the State/s the task needs to be in for the field to be viewed or its value modified within the Create Message view. Whether the User is able to view and/or modify is controlled by the User’s permission to create that Message type.

37. Workflow custom field permissions matrix • Permissions • Message Type Permissions

38. E-mail submission permissions • In order to be able to submit either a Message or a Task to TrackStudio via e-mail the submitting user must have: • in the case of Messages, been granted access to the Task, in the case of a Task, been granted access to the Task’s parent. • in the case of Messages, permission to create the default Message type of the Task’s category, in the case of a Task, permission to create a Task of that category. • If self-registration is enabled, it can be configured so that e-mails submitted by a User automatically get created as sub-tasks of a Task to which only that user has access.

39. Usernames and Passwords • TrackStudio may be configured so that usernames/logins are case insensitive. This means that for ease-of-reading you might create usernames with the format: • FirstnameL • But that users can type: • firstnamel • Passwords are case sensitive. • Note that a Superior’s password may always be used to login when using a Subordinate’s username. This is very useful when a single user is testing a workflow.

40. Thank you for listening Any questions?