Elastik - Why you should use it
Jun 7, 2011 · 6 minute readCategory: programming
This is post is now quite old and the the information it contains may be out of date or innacurate.
If you find any errors or have any suggestions to update the information please let us know or create a pull request on GitHub
The Problem
When working on any type of development project be it a design, programming even construction problems within the project will almost certainly arise. Keeping track of the problems that people have brought to attention can be hard to do effectively. Issues might be raised by email, IM or in person. Keeping track of the issues that have been raised can be a real problem if you don’t keep on top of it. Even on a single person project, it’s so easy to forget that some one pointed out a small problem. Using email and noting systems to track what issues have been raised can work for a small project but will quickly become difficult to work with one there is more than a single person on the project, such system of working will also fall apart if the number of current issues becomes large. Using a system designed to rectify the issue really is a boon. It not only allows each issue and it’s status to be tracked, but also standardises the method of communication so that every one knows where to look to see what is happening with an issue. Ultimately, the best benefit of using a tracking system is not losing/forgetting about any issues that have be raised. Elastik’s intended use is for multi-client multi-project purposes. That is to say Elastik can have many clients using it, each client having multiple projects.Creating Account and Account Permissons
Account creation of elastic is done via email on a invitation only basis. Only System, Project or Client Administrators can invite additional users. Elastik has quite granular user permissions. To start with there are three types of users Administrator, Client users/administrators and Project users/administrators. In terms of access levels Project users/administrator are the ‘lowest’ permission’ed user as they only have access to a single project. Client users/administrators have access to all the projects that a client has and system administrators have global access. On top of these levels of access, Client users can also be administrators of the client and the same applies to project users. Elastik also has granular per-project and per-client permissions settings available. In summary, if you want to tightly control access to the tracking system, you can do it in great detail.Setting up a client project
Elastik uses the concept that each project belongs to a client. Even if you are making an application for your self, there is still a client involved (you!). So before you can create a project you need to create a client. This is a way of grouping projects together as well as defining a client owner. When creating a client you are required to supply an email address. The person who owns this address will be given client level access and will have client access permissions, and there for access to all project that belong to that client. Client administrators can change settings related to the client and all the projects that belong to that client. If you do not wish to setup any client level access you can enter a existing system administrator’s email address and then add a new user to the client/project later. All this also applies when creating a new project.Managing Issues
Tickets is what issue tracking is all about. Ultimately working with tickets can be as straight forward as you like or as complex. Using the default ticket categories and schema will be enough for most situations and will even be workable even if they are not. However, Elastik allows you to create much more complex ticket structure which should make it flexible enough for use with any project.Customising Tickets
The default ticket structure is that a ticket can either be a new feature request or a problem within already existing functionality. You can either expand or shrink this as necessary on a per client or project basis.The default ticket schema is that a ticket can either be “Open” or “Closed”. You can customise this to have as many different ticket status as you like. Elastik also has the idea that it should be logically impossible to go one ticket status to a particular other one. For example, it would not logically make sense for a ticket to be able to transition from “Closed” to “New Ticket” as the ticket already exists so it is not a new ticket at all. In this example you would probably want to change to “Re-opened ticket”. Elastik allows you to specify that “New Ticket” is the default status of a new ticket and that it impossible for a ticket’s status to be “New Ticket” after is has already been changed, transitions can be defined to be quite complex.