Portofino 4 by ManyDesigns
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 | TYPE | RELATED 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 | RELATIONSHIP | User | 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 | RELATIONSHIP | project | the related project |
Ticket type
| ATTRIBUTE | TYPE | RELATED TABLE | NOTE |
|---|---|---|---|
| name | TEXT | 'Improvement', 'maintenance', 'new feature', 'problem' | |
| description | TEXT | 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 | |
| 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 | RELATIONSHIP | User | user reference |
| user group | RELATIONSHIP | UserGrp | 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!