For those using trouble tickets, what are the features that are important to you.  There are reasons why I'm not interested in supporting the eTicket module, all of which are my own.  However, HCL stands to gain a lot by having trouble tickets.  By knowing what features are important to you, I can either find a replacement, a set of donor code that would be translated into a full fledged module, or integrated (such as eTicket was).  Of those options, the last is the one I like the least.


<personal opinion>

I don't hate eTicket, nor do I think poorly of it's developers, they have come a long way with an old bloated TT system.  It's great stand alone.  In fact there are a LOT of great standalone systems.  However the integration system is really a hack.  It's not clean code, and trying to maintain a HUGE TT system just isn't going to happen by me.  Too much of the current osTicket/eTicket system requires near rewrites of chunks of code.  Not to mention the varied programming standards, and you have a real mess.

Should the eTicket module be continued, absolutely, but not by myself.  I simply can't do all of the work, HCL is a labor of love, it's something I really enjoy working on.

At this point I think it would be quicker to write fresh code or modify a more simple TT system then try to get eTicket even close to stable.  This week we've had issues of all variety, things that initial testing did not discover.
</personal opinion>

My gut feeling is that most folks want a SIMPLE to use, basic trouble ticket system.  Nothing glamorous or fancy, but collect the information and provide it to operators and support staff.

I'm gonna go through this line by line.

Actually, it would use the template system, so that it can be themed to the individual site

This is easy, simply use the mysql id number

Um, HCL already has these...  We can reference an HCL dept.

Ditto, already handled by HCL.

Shouldn't be too difficult.  This is mostly pretty standard PHP code.

Ok, and maybe have it optional for operators to assume unclaimed tickets.

again, some people want ops to be able to do this, so maybe a config switch.

Makes sense

Or maybe just a link that is sent with the first report of the problem, let them click the link and look up the problem.  Use a random MD5 hash to use for authentication, then they don't need a "login"

Again, makes sense for an admin overview.

What purpose are you thinking about?

Hmm, I can see this being needed by ops as well, if you have a lot of tickets.  It would be more of a sort and filter.

Initially yes, but once 2.2.x comes around, it will have built in banning, if their spamming the tickets, you probably don't want to live help them.

Again, maybe a switch to allow ops, some will want it, some won't.

Yes, very important.  Thinking that when the new windows/linux native app is done, allow this to interface in as well.

On the advanced idea, that will be possible in 2.2.x, and maybe in 2.1.x (future versions).

All in all great ideas!

Ah, ok, that makes much more sense.  Generally, I use the term visitors of people surfing the site, operators for staff without configuration access, and admin for the boss...

I'm using your list as sort of a road map.  After the e-mail I received from someone over at eTicket, I'm not going to even try to get it running.  I've actually downloaded phpticket, which is a minimalist TT system, and and basically rewriting it.  The basic reason for this is that I can cheat and re-use some of his code for now, and rewrite the rest in version .2 or something.

I should note, it won't be phpticket when it's released, in fact it can't live on it's own, the first thing I did was remove all authentication and now am removing all straight HTML.  Most of the classes are being redone, and nearly all the configuration is as well.  There is no need to replicate what is already in HCL.

Auth:

Look at the eTicket module, in the /hcl directory is an easy way to share logins.  Additionally it wouldn't be hard to add an integration module to replicate logins into HCL/TT

Flag:

Ah, so a status flag, that makes a lot of sense.  At some point it would be good to make the flags and their related status' admin definable.

Block/Ban:

This part of 2.2.x is still in the "dreaming up ideas" stage.  So it would be easy to add.  I'd like to have it setup so there is a user definable message that could be displayed/e-mailed.  That way the person knows why they are banned/blocked.

Hi MLZ

Newly registered to your new forum and site.  I have been using HCL for several years now and am still on version 1.2.6 so I guess it is about time for me to upgrade I guess.  I am just not sure if all my information will pull over to the newer version or not.

The simplicity of the HCL program is what has worked for me and I use HCL for customers to log in and either ask for sales assistance (sales department) where they enter in what it is that they are looking for and I get back to them with an e-mailed quotation but use HCL to track and "open and close" the request ticket so that both the customer and myself can see what is open and closed and we have archiving to go back and look at all the items.  The second department I use is labelled (repairs) where the customers enter in specifics as to the Make, Model, Serial #, what accessories they are sending in, what the problem is with the unit, their own Lotus Notes Tracking #, and radio user's name and department, etc.  The third department I use is termed (system down) and is for major problems that require an immediate service call to the customer's site.  Here they describe the problem and location and any other pertinent information that we need in dispatching a technician.

I link the departments to specific operators so that (sales) requests go to specific sales operators, (repairs) go to specific repair operators, and (system down) requests go to technicians who can handle the call.

I like HCL as it automatically e-mails us or the customer upon entry of a ticket or any update to the ticket and also provides the convenient link to go right to the ticket.

One thing that would be nice to add would be a feature that I believe was in oz ticket where you could create specific line item entry templates (text boxes, drop down boxes, radio buttons, etc) and save them and then you could create a specific 'home' or entry page per customer.  Having these line items then go to the MySQL database would help in finding a specific unit in the 'open' or 'closed' tickets and would also assist in cleaning up and structuring the entry of a ticket by the customer especially when more than 1 person is entering tickets.

Along the same path as templating the entry screen would be the capability of somehow customizing the departments such that there could be special departments that are only accessible to specific customers or so that a (sales) only customer would not see the (repairs) and (system down) or other departments.

Thanks..