Thanks Yoseph

Hi, just to address, there are two options I'm working on at this point:

1) App-less (just changed your contact settings); and 2) I am tinkering with some local app stuff for the folks who want it.

The focus right now is 1), but the point of getting out so early is to validate these assumptions.

Thanks for the feedback / questions.

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.

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.

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

Thanks for that.

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.

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.

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.

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).

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.