The TrackStudio Permissions model

1. The TrackStudio Permissions model Click to move between slides. Within each slide elements will appear automatically. 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 The TrackStudio Permissions model

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. The TrackStudio Permissions model

4. Essential concepts • A User’s own/base 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 The TrackStudio Permissions model

5. Own/base Status • Each user within the TrackStudio system has an own/base Status • This status is displayed in the user’s profile: The TrackStudio Permissions model

6. Status availability • The Own/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. The TrackStudio Permissions model

7. Own/base Status rights • Own/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” The TrackStudio Permissions model

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

9. User field-related permissions • These can be seen on the User Overview page: and are edited under the User Field Security tab The TrackStudio Permissions model

10. Task object-related permissions • These can be seen on the User Overview page: and are edited under the Task Security tab The TrackStudio Permissions model

11. User object-related permissions • These can be seen on the User Overview page: and are edited under the User Security tab The TrackStudio Permissions model

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

13. Assigned Statuses within context of a Task • In the context of any Task a user can have one or more statuses. • If a user is has been granted access to a task higher up the tree the status/es he/she will have in the current task are those he/she has inherited. • When a user is granted access to a task the Status he/she is given by default is his/her own/base Status. • Within the context of a task a User’s inherited or own/base Status/es may be: • left as it is/they are • complemented • overridden The TrackStudio Permissions model

14. Bill Richardson’s inherited status of 001 department manager is overridden by 030 software developer and that status is complemented by 040 software tester. Note that checking more than one Override check box for any particular user is not necessary. Inherited and base/own Statuses left as they are. Charles Parmenter’s base/own status of 030 software developer is complemented by 040 software tester. Note that although his base/own status is not visible in this view, it is still there as it has not been overridden. Assigned Task Statuses example The TrackStudio Permissions model

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

16. Behaviour of Statuses • If a User, within the context of a Task, has multiple statuses, the rights conferred by each of the statuses are added together. • The absence of a Status permissions (not being allowed to do something) takes 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. The TrackStudio Permissions model

17. Statuses in practice • Three types of Status can be created and employed: • 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 may also be used to identify who may do what in the context of Categories, Workflows and Custom Fields. The TrackStudio Permissions model

18. 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 The TrackStudio Permissions model

19. 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: The TrackStudio Permissions model

20. 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. The TrackStudio Permissions model

21. Users and Task Tree connections • In the as-installed DB different users are connected to the Task Tree at different points: The TrackStudio Permissions model

22. 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”: Users and Task Tree views • Each user sees only the Task/s to which he or she is connected and any of its/thier sub-tasks: 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. The TrackStudio Permissions model

23. 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. The TrackStudio Permissions model

24. 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. The TrackStudio Permissions model

25. 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: The TrackStudio Permissions model

26. 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 The TrackStudio Permissions model

27. 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. The TrackStudio Permissions model

28. 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*. 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: *Note that the “Can Create” permission references user’s task-related-assignation in the PARENT task. The other permissions reference the CURRENT task. Thus Can be handler = Submitter means that only the user submitting the current task can be assigned as its handler. By default the Handler of any Task is the Handler of the Parent task; therefore if Can be handler = Handler, the handler of the Task cannot be changed by the User submitting it. The TrackStudio Permissions model

29. Permission matrix worked examples • For example, suppose that the following permissions are set: • developer: Can be handler = handler • tester: Can be handler = all • this means that the list of available handlers will include all testers AND the current handler of the parenttask if he/shehas the status“developer”. If parent task assigned to a user with status“manager”, the list will include only testers. • To enforce the following rule"this bug can be resolved only by assigned developer, or by anymanager" set the following permissions for the Resolve message type: • developer:Can process = handler, • manager:Can process = all. • To enforce "developer can close a bug, that he/she has submitted" set the following permissions for the Close message type: • developer:Can process=submitter The TrackStudio Permissions model

30. 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 The TrackStudio Permissions model

31. 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: The TrackStudio Permissions model

32. 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! The TrackStudio Permissions model

33. 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. The TrackStudio Permissions model

34. 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.) The TrackStudio Permissions model

35. Workflow message permissions matrix • This works in exactly the same way as the Category permissions matrix. See slide Understanding the permission matrix The TrackStudio Permissions model

36. 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 The TrackStudio Permissions model

37. 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. The TrackStudio Permissions model

38. Workflow custom field permissions • In the as-installed DB the Product Lifecycle Workflow has Custom Fields. • Workflow Custom Fields have: • 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. • Message Type Permissions 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. The TrackStudio Permissions model

39. Workflow custom field permissions matrix • Permissions Message Type Permissions The TrackStudio Permissions model

40. 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. The TrackStudio Permissions model

41. 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. The TrackStudio Permissions model

42. Please submit questions or comments to support@trackstudio.com The TrackStudio Permissions model