Shown HN: Open Source Ticket Desk app | Hacker News Reader

Shown HN: Open Source Ticket Desk app

github.com

47 pointsAlexBlom31 comments

Have you considered fleshing this out? I have a few ideas about customers I'd like to try out... I'm interested in forking, but would like to know where you want to take this.

Edit: Sorry, I've just realized that I haven't really contributed a lot to this on HN. Specifically - how does the ticketing system work? What is the difference between a ticket and an issue? It seems that you can have a ticket that has many issues, but issues can have many tickets...

Does an issue encapsulate a lot of tickets? If so, is the primary work done on the ticket or the issue? The reason I ask is how do you allocate the unit of work to specific people.... or is this not the point of the app?

Sorry in advance for the huge number of questions.

Hi. I may flesh it out, but I've also opened up the software. If you have extension ideas, please feel free to fork / contribute. You can flip me an e-mail (my first name @ my HN username . com) if you want to go further, or flip a note on Twitter.

An issue has a one to many relationship with tickets. I built it, as I found I'd get many tickets about the same thing from different users. I wanted to be able to focus on solving the macro issue and not manage many issues. Terry Smith is one of the thinkers behind it.

I might be missing something here, but in ticket.rb, it has the line:

  has_many :issue

and in issue.rb, it has the line:

  has_many :ticket

Why a M:N mapping of issues to tickets? Were you planning of future expansion?

Perhaps I mis-spoke above. An issue can be associated with multiple tickets, just as a ticket can be associated with multiple issues. The latter is not beefed as much in the code, as I found the use case to be less once live.

I'm using Redmine in a similar setup. Have you seen any performance impact of rake tasks to pull imap mails ? I'm a little wary of the rake task loading the entire ruby (in my case Rails) environment, everytime it starts up.

any thoughts ?

For my use case it's fine. If the software was going to be commercial, this module would be the first to need beefing. I've toyed with re-running delayed jobs, but this setup has worked for me (Micro EC2 instance).

It depends upon the hardware you have. But if you have a decent machine say EC2 small instances or something like http://www.hetzner.de/en/hosting/produkte_vserver/vq19 it should not be an issue. We use similar setup for promptcloud and that machine has numerous other things running too, there is no noticeable load.

There is an impact, we have a Rack task that handles mail via STDIN and it takes quite a long time (5 seconds) to startup and process.

The app looks great. I wanted to point out the following (I might be missing something here) -- When I'm on the Customers tab, I see 0 open tickets for Alex B but when I click on Alex B and see his detailed page, I see 4 open tickets.

I like the ease of responding to (posting to work log + emailing submitter) of a ticket, and except for excessive whitespace the look is pretty attractive, too.

That said, it is lacking so many critical features any business of significant size would need to take it seriously, and to be honest, the market is glutted with good options of all costs and capabilities so I'm curious to know what your intention was in creating this?

I like the simplicity. I personally really like to have either tags or at least status field for issues. I know some people just like open/closed but for our team we have thousands of tickets that pile up so we need to keep them organized in some way. nice work on the app though!

Thanks. It's easy to keep things simple when you are building for my use case, which was rather basic.

That being said, I see the value of tagging. Perhaps a future addition.

It looks nice, I like the simplicity. One nit pick: I'm not too fond of the flash notices. Fading out and then suddenly being removed from the document, causing all content below it to jump up, is slightly jarring IMHO.

Appreciate the feedback. Will see how often this is reported. The fading is also handled in the main JS file, so you can disable it there.

Thanks for open sourcing it, great work. Sorry for the stupid question I have not much experience with this type of app. How do customers create tickets? I'm not exactly clear of the workflow, could you elaborate?

Sure. You create a support e-mail. Customers send to this e-mail, and tickets are auto-created.

Thanks for that.

It's might also be worth checking out allocPSA.com, also open source, and has a similar ticketing email gateway thingo... and a little tiny bit more functionality. (I'm very biased though :-)

I got “Sorry, this tree is taking too long to generate.”

http://d.pr/i/uqlG

Haven't seen this before…

Since the mail-integration isn't enabled on the demo, I couldn't test it, but I wonder how well it deals with stuff like signatures, attachments etc.?

I'll admit there is not much logic here. Was not needed for my use case. Feel free to contribute it, though!

Yeah, I might. I think https://github.com/github/email_reply_parser might come handy here.

Good call. Would love to see it integrated.

This looks great. I really want to get this working and then after a week, "hey boss, support seems better now huh?"... :-)

I'd like to see the first text box on a form be automatically selected when the page loads.

Would be great to see a working demo of some kind, or screenshots!

Fair. I've got an EC2 instance booting up right now.

Yes please, it is hard to judge whether this is a good option without screenshots or demo.

Demo is up (loaded with some of my testing data, so no real guarantees):

www.ticketdesk.co alex@ticketdesk.co 123456

I've disabled much of the cron / emailing.

I can't register :( I get a rails error page.

Reply on news.ycombinator.com