Ticket Tracker - Users, permissions and workflows

Heads up! These docs are for Portofino 3, which is a legacy product. Check out Portofino 4!

Posted by Giampiero Granatella
on September 11th, 2009

In this tutorial we are going to improve our "Ticket Tracker" application by introducing permissions. Permissions allow the modeler to specify who can create, update, or delete the system's objects. Permissions can go to a fine level of granularity, up to individual attributes.

This tutorial is the third of the ticket tracker series. If you haven't read the previous ones, you can find them here:

Before we start, we also have to activate user management as explained in the tutorial: Understanding the basic user management.

The scope

In the previous tutorial (Understanding Workflows) we created a simple model to manage tickets and their state. In that model all users could create a ticket, write/update its attributes and change its state.
In this tutorial we want to manage different kinds of users and their rights on the model's objects.
To break down the problem, we're going to express the system's functionality as a set of use cases.

We define four actors:

User: the generic user of the system
Creator: the person who raises a ticket
Manager: the person who assigns the ticket
Assignee: the person in charge of resolving the ticket

The responsibilities/permissions that we assign to the actors are as follows:

(Generic) users can browse all the tickets without modifying them.
Creators can create tickets and insert/change their details while in the open state.
Managers can assign a ticket to an assignee. Also the manager is responsible for the ticket's workflow state.
Assignees are responsible for resolving and eventually closing a ticket.

In the next sections we deal these actors and their use cases.

1. (Generic) users

Users are all the members of the "User" group. They can simply read the ticket attributes. Using the techniques we've seen in Understanding the basic user management, let's give the (r)ead permission to this actor:

go upstairs,
select the "Ticket" class,
click on the "Permissions" button,
click on "Add Actor",
while on the "Add Actor" page, elect the checkbox for "Users",
click on "Save": you'll be redirected back to the permissions page.

The permissions page contains an advanced permission matrix, due to the workflow on the "Ticket" class. This adds an extra dimension - the workflow states - (see the reference manual: Workflows), therefore we have to specify permissions for each actor in each specific state.

See the following picture and set the permissions accordingly:

In our example, Users (A1);

cannot create or delete tickets;
can only read the tickets attribute in all defined states;
can read the solution only in the "close" state (because it is written only in the "work in progress" state by the assignee);
cannot activate any transitions.

2. Creators

A creator is the user who has raised a ticket. Creators can change the ticket's data until it is in the open state.

First of all, let's model the creator as a relationship of the ticket which automatically connects it with the user during the creation. Portofino does it with the "auto connect to user" property of a relationship attribute (see the reference).
So let's create a relationship property: "reported_by", which will be required and will have the "Auto connect to user" property selected, as shown in the following picture.

Now we can identify the new actor: the user that has a path to the ticket through the relation "reported_by".
Follow these steps:

go upstairs,
select the class "Ticket",
click on "Permissions" button,
Click on "Manage Actors",
Here we have two group actors ("User Administrators" and "Users") and one path actor. DownRelSegment("ticket", "reported_by") means: from the "Ticket" class follow the relationship "reported_by" to the "User" class (see path actors).
Select the "DownRelSegment("ticket", "reported_by")" checkbox and click on "Save".
Set the permissions for actor A2 as follows, then click on "Save"

The creator can modify tickets only in the "open" state and only if they have been created by himself. He can modify his ticket's attributes (except for the "solution" , the "state", and the relationship "reported_by") while it is in the open state.

3. Managers

Managers are a group of users who assign the tickets, and are responsible for their workflow. To assign a ticket, we have to create the attribute "assigned_to". "Assigned_to" is a relationship attribute to the "User" class as "reported_by" relationship. But in this relationship, we don't check the auto connect to user because this connection is explicitly set by managers.

To create the managers group:

go upstairs
click on the "Meta User group" tab
click on "Create"
insert "Managers" as name
click on save

Notice that downstairs a user group with the same name will also be created.

Having a new user group, now we can update the actors and the permissions on the ticket:

go upstairs,
select the class "Ticket",
click on "Permissions" button,
click on "Manage Actors",
find the new checkbox for group actor "Managers", select it, then "Save"
in the permission matrix a the new actor (A3) appears; grant it permissions as follows, this paying attention to the 'Transition' section too:

Make sure that A3 has:

(r)ead permission on "state" and "reported_by",
(w)rite permission on all the other attributes, especially on "assigned_to",
permission on the transitions "start work", "resolve" and "reopen".

4. Assignees

The last actor is the assignee, the user connected to a ticket through the relation "assigned_to". This creates a new path in the "manage actors" page: DownRelSegment("ticket", "assigned_to).

We can use the new actor (A4) in our permission matrix. You can see the final version of the permission matrix in the following picture:

Notice that the assignee has the same rights as the user, with these exceptions:

he can (w)rite the attribute "solution" in the "work in progress state",
he can activate the "resolve" transition.

Conclusions

In this tutorial we've learned how a modeler can define the system's users and how to grant them permissions.

The permission system does not care about individual users. Rather, it uses the more abstract concept of "actor", which can be given by:

the membership of a user to a group or by
the "object/relationship path" that connects a user to a given object.

In the tutorial we've given example of both types of actors:

users and managers as group actors,
creators and assignees as path actors.