Show HN: Deskulu – Opensource knowledgebase and ticketing system

Show HN: Deskulu – Opensource knowledgebase and ticketing system(github.com)

137 points by farhadhf 10 years ago | 27 comments

reitanqild 10 years ago |

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

darkvertex 10 years ago | |

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.

vijayfreshdesk 10 years ago | | |

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

brazzledazzle 10 years ago | | |

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.

reitanqild 10 years ago | | |

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

debaserab2 10 years ago | |

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.

themartorana 10 years ago | |

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

debaserab2 10 years ago | | |

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

reitanqild 10 years ago | | |

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.

SwellJoe 10 years ago |

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?

codegeek 10 years ago |

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

mfkp 10 years ago | |

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

hobofan 10 years ago | | |

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.

ams6110 10 years ago | |

Or, your organizations own email server....

pbreit 10 years ago | | |

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

cyphar 10 years ago |

+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?

ocdtrekkie 10 years ago |

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.

farhadhf 10 years ago | |

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.

sarreph 10 years ago |

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

xxdesmus 10 years ago |

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

farhadhf 10 years ago | |

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.

the_ancient 10 years ago | | |

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

mahdiponline 10 years ago |

Awesome. Thank you.

behnamakradi 10 years ago |

Good