The TrackStudio Permissions model

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

5
Own/base Status

• Each user within the TrackStudio system has an
  own/base Status
• This status is displayed in the users profile

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.

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

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 Task Security tab

11
User object-related permissions

• These can be seen on the User Overview page

• and are edited under the User Security tab

12
Setting Task or User field-related permissions

• Some permissions cannot be changed

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 Users inherited
  or own/base Status/es may be
• left as it is/they are
• complemented
• overridden

14
Assigned Task Statuses example
15
Effective Statuses

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

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 Users 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.

17
Statuses in practice

• Three types of Status can be created and employed

• Statuses with rights that 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.

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
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

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.
21
Users and Task Tree connections

• In the as-installed DB different users are
  connected to the Task Tree at different points

22
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.
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.

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.

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

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

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.

28
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
users 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.
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 parent task if he/she has 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 any
  manager" set the following permissions for the
  Resolve message type
• developerCan process handler,
• managerCan process all.
• To enforce "developer can close a bug, that
  he/she has submitted" set the following
  permissions for the Close message type
• developerCan process submitter

30
Categories the final step

• Having created your Category, dont forget to
  make it a sub-category of an existing Category.
• See Slide How to create a Relation

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

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!

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.

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 dont change a
  Tasks 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
  Tasks 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.)

35
Workflow message permissions matrix

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

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

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.

38
Workflow custom field permissions

• In the as-installed DB the Product Lifecycle
  Workflow has Custom Fields.
• Workflow Custom Fields have
• Permissions

For the TaskgtEdit 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 Users permission to
create that Message type.
39
Workflow custom field permissions matrix

• Permissions

• Message Type Permissions

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 Tasks parent.
• in the case of Messages, permission to create the
  default Message type of the Tasks 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.

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 Superiors password may always be
  used to login when using a Subordinates
  username. This is very useful when a single user
  is testing a workflow.

42

• Please submit questions or comments to
  support_at_trackstudio.com