The aim of the project is to automate a Project Management System for issue-tracking tickets named Ticketee, in an agile-like fashion. Ticketee is a ticket tracking application to track company’s numerous projects. Ticketee can be used by organizations to assign projects to teams and track the project’s development cycle.
To start a development cycle of a project, project will be created by an administrator. Each project should have its name, description and a unique identity attached to it. Then, to manage the development cycle easily, the project is divided into subtasks by the project manager. Each subtask is known as a Ticket. To create tickets for a project, you need an idea of what you’re going to implement in a particular subtask. Team members can then create tickets based on the subtasks assigned to them, within the scope of the project. They can also use tickets to give any suggestions or to specify any problems related to the project developed so far.
Each Ticket must have a name specifying a task, a description about the operation which the ticket must perform, a unique ticket ID, and information about the author who created the ticket and the current state of the ticket, and some tags names so that similar tickets can be grouped together. A ticket may have many tags on the basis of which it can be searched.
The general workflow of a ticket starts when a user files the ticket, the ticket will be classified as a “New” ticket, and it means that the ticket is up for grabs. The next phase of a ticket’s life is the “Open” state, which means that the ticket is being looked into or cared for by somebody, and once they’re done they’ll mark it as “Resolved” or “Closed”. If a ticket needs more information, they’ll add another state, such as “Needs more info.” A ticket could also be a duplicate of another ticket, or it could be something that the developers determine isn’t worth working on. In cases such as these, the ticket may be marked as “Duplicate” or “Invalid”. The point is that tickets should have a workflow and that workflow should revolve around state changes.
Currently, Ticketee has four states “New”, “Open”, “Closed” and “Resolved”, which can be added to a ticket. Each state is represented by its name, a unique color, and a unique ID. Only admin should be allowed to add more states, rename a state, delete a state, and to set the default state if no state is mentioned while creating a ticket. Adding a default state will provide a sensible way of grouping tickets that haven’t been acted upon yet, making it easier for them to be found.
For changing the state of a ticket a comment must be made. Each comment must have some information related to the work done due to which change in state is being made, details of the previous state which the comment is changing and information of the author who created the comment. A Ticket can have many comments, but the state of the ticket is determined by the last comment made on the ticket.
Each ticket may contain a number of file attachments to provide more information about that ticket related to a problem or suggestion. A ticket description for a suggestion saying “This button should move a bit up” could be better explained with a picture showing where the button is now and where it should be. File type may be a picture, a crash log, a text file. This will give the project owners a useful context that will help the project owners a useful context that will help them more easily understand what the ticket creator means.
Information stored about each user includes their unique user ID, user’s name, his email and password. And a user can also be an administrator. Every user must be authenticated before performing an operation. Each user can have different roles for different projects, which are assigned to him by the administrator. A user can be a manager for a project granting him the ability to manage tickets for that project, and also administrate some facets of the project itself, including editing the project’s details. He won’t be able to delete and create new project, though—that’s reserved for administrators. User can also be an editor for a project granting him permissions to view the development cycle and also create and update tickets on the project. For people who will be able to read everything on the project but not edit anything are assigned the role of a viewer.
Ticketee sends users updates about important events in the system, such as a ticket being updated. A user is automatically subscribed to a watchers list whenever the user creates a ticket. Every time this ticket is updated by another user, the creator of the ticket should receive an email. This is helpful because it allows users to keep up with data with the tickets they’ve created. Users can also add themselves or remove themselves from the watcher’s list for a given ticket.
Webapp for the project is developed in Rails and Deployed on Heroku.
Although, you can sign up but you won’t be able to work on any project until admin grants you necessary permissions and roles.
This was a team project, created as a part of the DBMS course.