Elastik - Why you should use it

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

If you are looking for a light weight, fast, PHP based yet fully featured issue tracking system, Elastik is a great choice. Here is a quick start guide for it’s usage.

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.


Elastik has a modular design and comes pre-packaged with a number of modules all of which are disabled by default, presumably because some people may simply not want them. Below are two that web developers who often spend allot of time communicating with clients may find particularly useful.

E-Mail Summaries

By default Elastik only uses email for setting up accounts and nothing else. The email summaries module will send emails to individuals periodically informing them of changes made on a project or client. This does require a cron/scheduled task be setup on a computer to function however. This is particularly useful to keep clients up to date with changes to issues and also keep you up to date on issues the client is raising. One minor draw back is that by default it will only email changes to tickets to people who are watching the ticket. However, you can enable it to send every one on a project all updates whether they are watching it or not in the projects configuration.

File Attachments

The file attachments extensions allows files to be uploaded to the hosting server and attached (associated) with a ticket. Files are attached after ticket creation which does reduce the steamlined-iness of the process, but you can attach more than one file to a ticket. The one thing to watch out for when using this extension is that it defaults to not allowing any uploads and you have to explicitly define what file extension types can be uploaded on a per-client or per-project basis. You will most likely want to enable all image formats so client can upload screen shots of the issue.


If you are having any amount of trouble communicating and keeping track of issues for any type of project, using Elastik is definitely a good way to solve this. Elastik is fast, customisable, flexible, functionally complete despite been at version 0.4.1. No major draw backs despite been incomplete. Personally I would like to see it keep the light weight approach so that it doesn’t matter how old/rubbish a clients computer might be and they are using IE6 it will still be fast. It will also mean that if your server is over loaded, it will still run fast. Of course, if it doesn’t do what you want out of the box, it is PHP based and open source, you can either write a new module for it or fork it and start hacking at the code.