Nice work and thanks for sharing! And don't care about the PHP haters here.

For those who wants to go with hosted anyway, I'd recommend looking into Freshdesk instead of Zendesk.

Some reasons:

* Free tier up to three users

* Cheaper licenses once you leave the free tier. (IIRC)

* More features included by default in the free and lowest tiers. (IIRC)

Just be aware that a friendly Indian (or so I think) will call to try to upsell you : )

We use Freshdesk's "FreshService" ticket system at my workplace and the way it handles replies in one ticket from non-agents is absolute garbage.

You make a ticket by email, it adds to the system, a support agent is assigned to it, so far so good... then a developer with access to see the ticket goes to the ticket page and adds a helpful reply, except the ticket creator never hears about it. It's registered on the ticket web UI, but the creator of the ticket is ONLY notified of the responses by the support agent only. This sucks big time (and AFAIK is not configurable.)

Also god forbid someone uses email (or an email alias you're part of) to make the ticket and you accidentally do Reply All so your reply creates a brand new ticket just for you as opposed to appearing as a response in the initial ticket. It's so dumb. (You can get a ticket ID to put in a brand new email and then your reply would be registered but you need to know the ticket number first AND it still suffers the same issue that if you are not the support agent your reply is registered but never notified to the ticket creator.)

If your support is always 1-to-1 then by all means Freshservice is fine, though.

Hi Darkvertex. Sorry you had this experience with FS, but I blv you might have missed out some of the configurations in FS, which is why you feel the confusion. First off all, we dont block or restrict the developers from replying. While replying to the ticket, all you need to do is, toggle the option - Private/Public comment. For email replies this is very much configurable from your Admin > Observer rule. Create a rule to add a Public Note instead of a Private Note. If the reply is going to be via Email. If its going to be via the Ticket page itself, use the toggle below and change the reply to public. As for your 2nd point, we dont recommend using Alias emails because distribution list as Support or Helpdesk Email is a wrong method and has no accountability and hence we suggest using a proper support mailbox. This has been clearly mentioned in our Solution articles too, when you setup the Support mailbox. We suggest using a proper mailbox and use it in the system. Its just you need to setup the product in right manner, which will help you achieve you Support/Helpdesk model in the right way. If you need any assistance, we are more than happy to assist you

Thanks Vijay Freshservice Support

They should make it crystal clear that it doesn't send to the customer. That is garbage. But it makes sense if you think about it since you're likely paying per-agent. They don't want other users to workaround the licensing and act as agents since that's how they make money.

Ok, that's good feedback! I haven't used it wnough to notice. Thanks a lot.

I recently evaluated this space for my startup's needs. We ended up going with Uservoice because it seemed to be more "product focused". As we grow we can opt-in to the different uservoice products that focus specifically on more product management (things like idea aggregation/voting, feedback forums, roadmapping)

Our support volume is manageable by just a few agents. If we needed to manage teams of agents and different support channels, freshdesk or zendesk might have won out as they seem to be stronger in that area.

That said, you can't beat a free tier if all you need is a basic ticketing system. Just thought I'd share some of the other options out there.

PHP is fine. How do you feel about Drupal haters?

Some of the Drupal hate I would say is a little more justified.

Saying this as someone who inherited several drupal projects that would have benefited greatly if they were coded from scratch (well, with standard library/frameworks) instead of "done the drupal way".

I don't know enough to say. I though most of the the Drupal hate was because it was coded in PHP I used it once and found the learning curve steep but concluded it was just me.

Our current ticket tracker is Project Issue (the same one used by Drupal.org, sort of, though they seem to still be running a custom version). I dislike it a lot, and it was a tremendous pain in the ass to migrate from the Drupal 6 version to the Drupal 7 version. I'm hesitant to invest any more time in Drupal-based solutions to things because of how painful our D6 to D7 migration has been and how buggy and incomplete almost every module we use has been. (And, with most developers now focusing on Drupal 8, I don't expect any of these problems to ever get fixed in Drupal 7.)

But, this looks really nice, and since I'm stuck with Drupal for the foreseeable future (I can't afford to stop everything to do another migration at this point), I will likely look into how difficult migrating our tickets from Project Issue would be. I don't suppose there's already a migration for that?

Also, using a third party for notifications as you're doing is problematic; probably even a deal breaker, for us. Though, I understand the desire to not use Drupal notifications, as they're among the most broken parts of the system and have a clumsy API and very weak solutions to common things like bounce processing and mailed replies.

Finally, I'm super impressed by how fast some experienced Drupal folks can whip something up. I struggle for days or weeks to do anything with it. It's such a large system, and it always seems to take so much code to do even basic stuff (and forms API in Drupal is deeply ugly and verbose). That's my roundabout away of congratulating you for making something awesome in a very short amount of time.

Edit: You mention forums as a feature of this. Is that the standard Drupal forum module or something else?

"Need a Mandrill account"

You may want to rethink this one as Mandrill screwed their customers big time recently. So I hope there is a way to add other services like sendgrid, mailgun etc.

I second this, I recently switched my apps off of Mandrill because of their changes.

I assume the authors didn't want to deal with the different "incoming webhooks" from different services, but it shouldn't be too hard to implement in theory.

For reference, here's a list of SMTP providers which support inbound email: https://www.metachris.com/2016/03/free-transactional-email-s...

Does anyone know if they are trying to kill off Mandrill?

Shortly after they closed down the Mandrill login they closed down our account for a TOS violation without warning. Outbound emails immediately stopped sending and we had to switch to Sendgrid ASAP. Their support didn't cave one bit and it seemed like they were actively trying to lose us as customers.

Can you share what you were doing, and what they thought you were doing?

Do you also use Mailchimp to send marketing emails?

We had our main account which we used to send both marketing mails via MailChimp and transactional mails via SendGrid. There also was a old account that was used by a different department for partner newsletters, which was already inactive for a few months.

They disabled the account, which we only noticed because emails stopped sending, and their UI also didn't give any explanaition. We asked their support, they said the second account was a violation of the TOS. We explained the situation and they still insisted on keeping the account closed.

Now we are with Sendgrid and are spending much less on mails, but I'd rather have lived without spending the night restoring email functionality.

Don't bother with Mandrill. They clearly don't want to keep their transactional email customers and perhaps just want to focus on the marketing piece. After the way they handled mandrill, I wouldn't trust them anyway (and I was a paying client of mandrill). Go with Sendgrid, mailgun etc. for transactional emails.

Or, your organizations own email server....

Running you're own mail server is not a good idea if you hope to avoid ending up in spam folders.

+1 for GPLv2. Would you consider making it "GPLv2 or later", as well as including the three-paragraph statement of the license in all of the source files?

Any reason this shouldn't have straight up SMTP support built in? Was looking at an internal use for this right up until I noticed that requirement.

Simply because we were using Mandrill at the time of writing this. It's easy to add more methods like SMTP/SendGrid/etc to it though.

Great work! With such high per-agent pricing tiers on mainstream platforms such as osTicket and ZenDesk, this looks like a great alternative for startups and small teams :)

You lost me at: "Deskulu is an opensource helpdesk and ticketing system based on Drupal 7..."

I know Drupal is not the best or simplest thing for doing this out there. It's not even that good in terms of performance. But it's flexible and extremely fast when it comes to development time. Deskulu was not supposed to be scalable (it's not going to be Zendesk). I built the first version this over a weekend to handle our own tickets and then it's just been doing bug fixes/updates every now and then. It would've been impossible to do it in such short time with anything else (at least for me), and it's saved us hundreds of dollars over the past months. I'd call that a win.

Yes but it is not written in nodejs/rust/<insert lang of the moment> so clearly it is crap /s

Awesome. Thank you.

Good