This project has moved and is read-only. For the latest updates, please go here.

Extra feature ideas

May 17, 2009 at 9:21 AM

Hi all. I have downloaded the project files and have installed with sql server 2005. I would first like to say what a good job you have done this is a really good simple uncluttered help desk issue tracking system.

Some simple extra features i think it would benefit from would be: to have sub categories ie under software > you could have application name if you have more than one application managed for customers or just software problem type ie email, orders, .....

Also i think it would be good if when your an admin user you can edit all others users details, unlock, lock their accounts etc

If the above have been done, requested or you feel are nonsense then please reply as such, thanks.

May 18, 2009 at 9:25 AM

You can do something very similar to what you are asking about without sub-categories. You can create a category for each of your software applciations, but prefix each category with "-- ". Then you can order the list using the admin tool so the new categories are directly under their parent in the list. This generates a drop down list that might look like this:

-- keyboard
-- monitor
-- printer
-- windows
-- email
-- browser
-- network card
-- server


I will caution you not to over-categorize. This becomes unmanagable fast, becomes hard to administer and keep up to date, and complicates the process of creating tickets for you users. If you end up with a category called "other", "unknown", or something similar then you are certainly over-categorizing things. 

It isn't true sub-categories, but stilll presents a list that gives the options you are interested in. For more information about why sub-categories are not included in TicketDesk see the previous discussin about this here:




May 18, 2009 at 10:16 AM

thanks for your reply. I agree about making categories to complicated, and will try it as you said.

I still think being able to edit all users details from the admin login would be a good addition if not already done in a patch.

Also when creating a new ticket as an admin or ticket desk it might be a good idea to be able to relove/ complete it at the same time ie if a request comes in by email and you sort it you still have to log it so on creating the ticket you set its staus straight away to completed. A thought anyway.

Anyway just a few thoughts of mine. Is there anywhere that has a list of extras etc in mind for further releases etc that i can see.

May 18, 2009 at 5:42 PM

More comprehensive admin tools are part of the general plan, but I do not have a work item specific to the user editing tools. I will likely take care of this when I re-code the permission system (work item 9742).

Creating a ticket that is already resolved or closed is not a planned feature. If you want, you can create an issue in the issue tracker here and we can let people vote on the feature. I can see some value in creating tickets that are already assigned to someone (and thus don't generate "new ticket" broadcast notificaitons), but creating tickets that are already closed/resolved seems like it would activly encourage users to perform out-of-band work then back-enter the tickets. While sometimes things happen that way, I don't know that TicketDesk should encourage it.   

May 18, 2009 at 8:51 PM

Well I have been testing for a couple weeks now. The sub features is something I originally wanted to see as well. Reluctantly you talked me out of it, but as adding them with the sub feature of using –before the feature worked like a charm.

Noting this is open source and you probably didn’t expect this many requests I would like to add that if this is a user project and you want user input maybe you should convey some of our requests.

I think having the ability to turn features on and off for whomever wants them would be a great feature. Such as being able to close your own submitted ticket.

You have to log in. Assign the ticket to yourself ( with a quote of why you are assigning). Then you have to log in to close it with another (quote) when they could possibly be the same.

However. Using it as is. You are correct, most extra features aren’t needed !! ( pat yourself on the back here. ) However letting the user decide what is good for him/her seems to be more important. Let the user decide for themselves something isn’t needed then let them shut it down when they get to that point.

May 19, 2009 at 6:40 PM

I love that the project generates interest and user input. I didn't expect much actually. This isn't my first open source project by far, and past experience had told me this would be a very small one with very limited interest if any. Had I known that the project would have some popularity I'd probably have done more to market the "ideas" that I was working with... especially since the idea is to produce a purposefully simplistic system that deliberatly avoids some features that other help desk products consider "essential".

In choosing features, one of the primary requirments was that I keep the code itself simple enough to be easily maintained given the minimal amount of time I can devote to the project and the limited number of other people in the community willing or able to contribute code (so far). To keep the code small and nimble I have avoided optional features. I will not avoid them forever, just long enough to finish getting the system's core functionality finished.

Users here have influenced the design in ways I hadn't expected, and have forced me to re-evaluate some of the core design principals too. A lot of the existing 1.2 release was driven by the community here and I expect the next major feature release to go a lot further down that road.  But even if I eventually have to decline to implement a specific feature request, each one of those requests has an impact on the design. At the least they each make be re-think some existing features to see if those can be improved to eliminate the need for the requested feature, or if I need to plan a different strategy for future feature sets.

So keep the suggstions coming :)

BTW, I am currently deep in the process of converting TicketDesk to the MVC framework. I haven't decided yet if that will be the official direction for the next release of TicketDesk, but so far I'm leaning heavily in that direction. 




May 29, 2009 at 11:40 AM

Dear Stephen Redd,

First of all, i would like to congratulate you with this great portal. It is easy to configure, and easy to manipulate as a template.

Also i have some good idea's.

We are using this Ticket System with great potentionel. Tho i have one suggestion what could come in handy after some hundreds of tickets.

Search by Ticket ID.

I am not familiar with ASP/ but i don't think this is a big of a deal.

And again, keep up the good work.

With kind regards,

Jaivy Daam
ITM Department.

May 29, 2009 at 4:06 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 1, 2009 at 11:41 AM


I think another possible feature would be number of hours worked on a ticket in order to fix it where need be along with response times. I suggest this as people may have sla's (service level agreements) to uphold.


  1. repsone times (dependand on the priority {high = 1 hour, medium = 1/2 day, low = 1 day}) to an issue/ ticket being opened even if its just an  email stating users xx will be looking into this for you
  2. solution times again dependand on priority. The time it must be fixed by or a suitable solution found


Below is a report which i would need to provide. This is to show the extra items i/ the feature would require.

<font size="2">

Ticket No | 


Raised by | ticket type | Severity/ priority | Date Time Raised | Date Time of Response | Response within SLA  | Date Time of Resolution | Resolution within SLA | Date signed off


Again this is just my thoughts so if you dont think ticketdesk should go this way then fine as its you that started it. Thanks any thoughts here would be good

Jun 1, 2009 at 9:16 PM

Hi Jonnymaboy,

The issue you raise is a very sticky one indeed. Metrics-based management is a popular game, despite years and years of research and real-world evidence showing how dangerous it can be to an organization. 

Joel Spolsky actually writes quite a lot about this in numerous articles he has released over the years. His FogBugz issue tracker also fights a constant battle against these kinds of features.  

While I can't quite convey the idea as well as Joel does, the general idea is this:  

Anytime the issue tracker becomes a tool by which management measures employee performance, or by which managment "might" measure performance, the system ceases to have any value to the organization at all.

Even the most well meaning and mature of staffers WILL game the system. Anything that would make them "look bad" gets omitted. Tickets for some issues will simply not be recorded because the staffer will fear that it might reflect badly on them. Work gets performed off-the-books more and more often whenever help desk can manage it. The numbers that you do track will always be manipulated by the staff to reflect favorably on the staffers with no regard to actual accuracy. Tickets will be closed as soon as possible to inflate the response time numbers even if the work hasn't been fully vetted. Folow-up and verification after-the-fact will becomes highly dis-encouraged so that the staff can close out tickets as soon as possible. A re-opened ticket becomes a personal failure on the part of the staffer who closed it, and that ticket will suddenly gain an inflated priority that is out of proportion to the actual severity. 

Even if you have some honest staffers that don't game the system... the system will always punish those users while rewarding users that do game and manipulate the system.

The purpose of TicketDesk is to facilitate honest and open communication between users and help desk. If the system is used as a performance measurement system, it cannot provide honesty nor openness. The system will not be accuratly tracking real issues, thus it fails the primary mission. To complete the failure, any metrics you thought the system gathered turn out to be inaccurate which leaves management even less aware of the realities within the department then before.

Not only has research and experience shown this to be true, but I've personally experienced this phenomenon time and time again in my own career... and not just with help desk software, but also with development and bug tracking systems too.

Now... there are ways to do reporting in a way that doesn't create this problem. But it takes very very careful design. You have to deliberatly design reports that cannot be used to show performance metrics on any individual staff memeber or group. The reports have to carefully show the general higher level trends within the organization.

I do have plans to add some of this kind of reporting to TicketDesk in the future, but not until I've had the opportunity to thouroughly think out, plan, and design the reports. Most of the information these reports would need though are already part of the system. 

But the kind of reporting you are asking about will NEVER be part of the core release of TicketDesk.

Not because I don't like my users... I love you guys. But I won't add such features to the core release of TicketDesk because my own manager would then insist that we have access to those features ourselves. While he is a great guy, and understands the nature of what I described above no manager could avoid the temptation to use the reporting to measure performance. I imagine that if the report was there, I'd use it myself despite a personal, almost religious, objection to that kind of reporting... that's just human nature for you!

Now... as to your specific needs... TicketDesk can be customized to collect the information you want pretty easily. The reporting would also be fairly trivial to custom implement.  

I'll be honest with you though, if you have service level agreements to uphold you are propbably not using TicketDesk in the kind of environment it was intended for. You may want to seek out a much more complex system for your needs. 

Service level agreements indicates you are performing help desk lilke duties for an external organization. TicketDesk in the current form was designed only for internal use within a single organization where maximum levels of trust are assumed. That isn't to say you can't use TicketDesk in your environment, just that you have to keep in mind that you may have needs which a regular help desk tracker isn't equipped to handle. In your kind of environment, you would likely want a system that exposes some management and reporting functionality to the external stake-holders, other kinds of management and reporting functionality to the internal management, and then there are two kinds of end-user too... the limited-trust external end-users submitting tickets and the maximum trust internal help desk staff.

In short, TicketDesk assumes two target users groups where your environment has either three or four. That might seem like a trivial detail, but the way a system is designed at the core would be significantly different between those two scenarios.

I plan to evolve future versions of TicketDesk to make it more usable in limited trust environments with external users. But  full support for contracted help desk environments would actually require a different branch of TicketDesk to serve that market fully. I might eventually go that direction, but I'd probably do that as a commercial application instead as organizations using it that way would likely want formal software support agreements too.         




Jun 2, 2009 at 9:10 AM

thanks very much for your reply, especially the details you went to. In this case the number of users will be relatively low but even still i agree they would be able to "play the system" but its something we need to do as we have to show/ prove that the service level agreements are being met.  I think ticketdesk does most of what i need and is nice to use.

I will do some more reading from the above links you mention before attempting to do a design i think. Thanks again for your help.