Ticket Tracker - The data model

Posted by Giampiero Granatella
on June 17, 2009



In this tutorial, I'll show you the data model of the ticket tracker inside the one-click-start portofino package. This can be useful to understand better that example application.

A ticket tracker is an application to keep track of reported bugs or issues related to a project. Users can enter tickets directly, and these are managed and assigned to developers, testers, etc., who wiil work on them.

To better follow the model, I suggest that you download the one-click-start portofino, extract the files and launch your_dir/one-click-start-portofino-2.0.16/apache-tomcat-6.0.18/bin/startup.sh (or .bat if you use Windows). Your ticket tracker wiil start at http://127.0.0.1:8080/tt (use admin/admin to log in).

The class diagram

The following picture shows the class diagram of the ticket tracker.


As you can see in the model, there are eight classes, each with a certain number of attributes. There are also several relationships: one (User_UserGrp) is a many-to-many, the others are one-to-many's.
The main class is "Ticket", both in a "semantic" sense and in terms of number of attributes/relationships. The ticket has a priority ('hign', 'normal' or 'low'), a resolution ('resolved', 'not to be solved', 'duplicate', etc.), a type ('problem', 'new feature', 'improvement', 'maintenance'), and is associated to a project.
Also, it is interesting to see that it has tree different relationships with "User" to specify who reported the ticket, who is assigned to it, and who is  the approver.
Another interesting class is "Project". A project is a containter of tickets (as we've already seen) and of versions. Also, a project has a user in the role of leader.
Finally, User, UserGrp and User_UserGrp are the basic user model common to all Portofino applications, which can be set up easily using the "create user management" functionality upstairs.

A detailed view of the classes follows.

Ticket

 ATTRIBUTE TYPERELATED TABLE
 NOTE
 code TEXT  the ticket code
 project RELATIONSHIP project the associated project
 type RELATIONSHIP ticket type
 the ticket type
 description TEXT  a brief description of the issue
 priority RELATIONSHIP priority the priority (low, medium, high)
 resolution RELATIONSHIP resolution the resolution
 state WORKFLOW  one of the worflow states
 creation date
 DATE  the creation date
 update date
 DATE  the last update date
 summary TEXT  A brief summary
 assigned to
 RELATIONSHIP User The user that has to fix it
 reported by
 RELATIONSHIP User The user who inserted the issue
 expiry date
 DATE  the expiry date
 approver RELATIONSHIP User The user that has to declare the resolution
 close date
 DATE  The date when the issue is closed

Priority

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 name     TEXT  e.g. 'high', 'normal', 'low'

Project

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 name     TEXT  the project's name
 url TEXT  the website url
 description TEXT  a brief description
 code TEXT  a short code
 leader RELATIONSHIPUser
 the project leader

Version

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 name TEXT  The version name
 description TEXT  a brief description
 planned date
 DATE  the planned date
 actual date
 DATE  the actual date
 project RELATIONSHIPproject
 the related project

Ticket type

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 nameTEXT  'Improvement', 'maintenance', 'new feature', 'problem'
 descriptionTEXT  a brief description

Resolution

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 name TEXT  a short name
 description TEXT  a brief description

User

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 login TEXT  user's login
 password TEXT  user's password
 email TEXT  user's email

UserGrp

 ATTRIBUTE    TYPE
RELATED TABLE
 NOTE
 name   TEXT
  The group name (e.g. 'Users', 'User admins')    

User_UserGrp (as a relationship)

 ATTRIBUTE
 TYPE  RELATED TABLE   NOTE
 user RELATIONSHIPUser user reference
 user group
 RELATIONSHIPUserGrp
 group reference


State Diagram

The following picture shows a state diagram of the workflow associated to a ticket (workflow attribute 'state' in class 'Ticket').




Briefly a ticket is 'open' when an user reported it. The ticket is then associated to a user, who'll work on it and change its state to 'work in progress'. When the ticket is resolved, it change is state to 'Resolved', if the approver is satisfed by the "resolution" it can close the ticket or alternatively it can bring it in the "Work in progress" state.

 State
 open
 work in progress
 resolved
 closed

 Transition    from state
 to state
 start work
 open work in progress
 resolve ticket
 open resolved
 close ticket
 open closed
 reopen ticket
 work in progress open
 resolve ticket
 work in progress resolved
 start rework
 resolved work in progress
 close ticket
 resolved closed
 reopen ticket
 resolved open
 reopen ticket
 closed open

Conclusions

This tutorial has shown the ticket tracker's data model and gave a quick glance at the workflow model. There is much more to say about the workflow model, but this will be the subject of another tutorial. So stay tuned!