2

We are in the process of proposing a technology choice for a ticket management system (think of ticket in the sense similar to "work task", "incident report" or "support case"). I am not able to lay out the full specification here obviously but in short we can think of the system as a ticket management system with these special requirements:

  • The format of the tickets needs to be highly, not to say totally, configurable. That is, we need to be able to comply with a data model that our customer specifies for what a ticket looks like with a number of data fields that the ticket reporter needs to fill in into different formats: Multiple choice fields, text fields, Numerical, single choice. Mandatory and Optional. Etc. That is only a minimal requirement however, we'd feel much more comfortable if several different such data models or 'ticket templates'/'ticket types' can be specified in the system.

  • Likewise the different states that a ticket can be in need to be configurable. We need to be able to specify our own taxonomy of such states (say "new", "open", "closed", "pending approval", etc) and upon transition from one state to another we want to be able to specify that certain data fields will be locked for editing or hidden.

  • We must be able to trigger actions both when a ticket state changes and when a ticket property changes. Such actions can be to send a email or running a script that extracts and transfers data, etc.

  • Roles. The implementation of roles in the system must be flexible enough so that it fits a multi tenancy type installation. That is, we need to be able to group users in organizations. And within each organization we need one type of high privilege user (or organizational admin if you wish) entitled to create users of a low privilege type for that organization. Moreover we need low privilege global users, that can do simple tasks like view and edit some ticket properties across all organizations.

  • We need to be able to save and display history of edits on ticket.

  • We need to be able to set up the system working against encrypted database.

  • Change naming of views, headlines etc. in the user interface.

  • Nice support for producing reports and statistics is a bonus. Pluggable architecture where we can write our own modules is also a bonus.

The question is, do we have to build it ourselves or is there an Open Source system/framework that is feasible for this? Candidates could be Request Tracker, OTRS, Redmine. Or Mantis or SIT! (we do however have a bias in the group against going for something built on PHP). Other suggestions welcome if they really fit with the above specs. I would appreciate to hear some relevant experience here, if you have experience from trying to tweak one of the Open Source ticket systems in a similar manner or just sufficient expertise on either of them to say if the tweaks/requriements are feasible. Also, for the case that we end up building it ourselves (Java, RoR or other, everything possible except .NET or PHP), I am interested in smart tips concerning development frameworks/libs that could be useful when developing this kind of system.

1

Have a look at either of these Drupal based solutions:

Both solutions have an approach where you turn on the suboptions (apps or plugins if you want) that you're interested in, a ticketing system as you seem to be looking for is one of these suboptions.

I believe it satisfies most of your criteria ... except for 1 possible showstopper in your case: it's based on PHP (the newest Drupal 8 release is Symphony based ...). But apart from that: open source, totally configurable, roles support, etc (pretty much all your criteria seems to be covered). Though I'm unsure about "encrypted database" (since the criterium in your question can be interpreted in various ways). Did I mention it is "free"?

1

There is a free and open source version of xTuple PostBooks ERP - you can use whatever modules you need, such as the integrated CRM - http://xtuple.com/products/postbooks - you can try the free version.

CRM = universal address book, incident management (more than adequate for a ticketing system like you describe), opportunity management, to-do lists, project management

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.