While working on a project for the Palmetto Technology Hub, a couple folks from #CHSDUG and I found there are no great open source helpdesk systems. I've tried Storm and Casetracker, and they're too basic. Support Ticketing System logs notes as comments, so we lose the internal/external split and easy access control. osTicket is what we currently use at the Tech Hub and it's pretty mediocre. Most other open source options haven't been updated in 2 years or longer. All the proprietary options that are halfway decent are expensive.
In response, we're building a new distro called FLOSSDesk. I'm recruiting folks interested in helping with theming and a few architectural decisions. My goal is to use core and contrib code whenever possible to ease upgrades and ongoing management. We could also use some folks to assist with testing and trying to break it once we have an alpha ready.
Current features:
- Case creation by analysts or contacts
- Internal and external case notes, with a single chronological view of a case
- Automatic email to contact or analyst when external notes are added to a case
- Reply-by-email to notifications, with attachment handling
- Notification to old analyst when a case is taken over by a new analyst
- Ability to change case attributes (severity, status, assignment) without going into the node edit form
- View of "My Cases" for contact
- Views of "My Assigned Cases" and "All Open Cases" for analysts and managers
In development and planning (now through the next month)
- Responsive theme based on Omega 3
- Automatic service level management and escalation notifications
- only allow a contact whose organization has a support contract to view and create cases
- "admin" contact per organization, with ability to add or remove other contacts from the org
- View of "My Org's Cases" so that nothing gets dropped when there is org turnover
- Closing some holes in permissions
- Kit compliance
- Turning it from a handful of Features into a true distro
Sooner (3-6 months):
- microsite and screencasts to properly market the distro
- Ability for admin contacts to create new user accounts for their org
- Push/pull with SugarCRM, CiviCRM, vTiger, etc for organizations, contacts, and maybe cases
- Messaging integration for channel-agnostic notifications (growl, sms, etc)
- Integration with a reporting platform for managers. I did this with BIRT on D6 so it may be time for a port, and possibly a new contrib module
Later (6 months +) or maybe never:
- Mobile-specific theme for case viewing, and maybe case creation. I think we can use Delta and Context for this?
- VoIP integration
- Extension into a full support portal (knowledgebase, forum, ideation, downloads)
Even if you're not interested or able to help with the work, I'd love to hear your thoughts.
Comments
Any relation?
Sounds cool. I posted this thought recently: http://groups.drupal.org/node/171209 with the idea of building a way to bring feedback like you see in uservoice or zendesk via an overlay widget and pull into a helpdesk. It sounds similar to what you are thinking. Love to play / test / help... not a themer, can contib some code if need be.
My main thought / addition to what you are working on is a way to create a simple widget module and/or code snippet for bringing in cases and issues for whatever site. Any thoughts or current implementation of this?
If those apps do email
If those apps do email notifications when a ticket is created, our current features can turn them into cases. We use Mailhandler and Feeds to import new emailed cases, and to attach email replies as external notes on existing cases (similar to MailComment, but with full nodes). There's a small custom Mailhandler Commands plugin involved, and the pending commit of #1265818.
If they don't do email, I'm sure they each have an API and we can create a Feeds Parser/Processor/Mapper to turn them into cases with a couple hours of work.
Advice on getting the org user / org admin / org node security worked out would be helpful. I understand
thea helpdesk's security model quite well from working at various helpdesks over the last decade, but there are some scenarios that Content Access and Field Access just can't handle without custom code so I'll need to translate that model to Drupal.I'd like to give this a week or so to see if there is enough community interest to make it a real distro. If I can get 4 or 5 more recruits to help hack on it, I don't see it taking more than a month to get to alpha.
Is it okay to create a sandbox project for a distro, or is that just for modules?
Organizing a Community Built Project...
I don't think you are supposed to put full distros into the sandbox, especially considering issues with licensing for certain non-GPL things.
Do you use make files? I think the best and cleanest way to do this to separate as much as you can into different features, modules and an installation profile (each having their own git repository in d.o. or github), then have a make file (generally within the profile), which you can easily use $ drush make http://whatever-link-to-your-make-file.make to build and pull it together for developers. That's so you can have every part on the cutting edge for the developers and also makes it easy from someone to customize and add modules consistently.
I also think it is good to have a full distro with drupal and everything in a github repository too, but specifically only when you get to alpha1, alpha2, etc.
Does that make any sense?
Could make email....
I actually haven't built anything yet for this feedback widget yet :p
But we'd be talking about something very simple acting much like or as a webform via an overlay. I'd want it to specific it as a 1.) Bug / Issue/ Help Request, 2.) Idea / Suggestion, or 3.) General Feedback
So, yes it could be done with email. Just would need it to format in a way that goes into your issue / help desk setup.
Check out http://uservoice.com/ and click on the feedback box for what I'm thinking about. I sounds like we could get this
By the way, you doing this in D7 or D6? I'm still stuck in D6 for most of my projects. I teach basic D7 at a univ but haven't hacked on it yet.
This is all built on D7.
This is all built on D7.
Slowly but surely, progress is made
I've only had one other dedicated volunteer banging on this with me, so progress is slow. There have also been snags with some lingering issues in contrib (References missing a feeds integration, Mailhandler getting a plugin weight field added, a couple of large Rules bugs).
We have been polishing things that sort-of worked but were a bit flimsy. There are three Features now:
FLOSSDesk - the base feature that covers dependencies, content types, contexts, views, and permissions
FLOSSDesk notifications - a set of rules for case notifications and service-level agreement
FLOSSDesk reply by email - does what the title says
We couldn't figure out some of the quirks of Omega 3, so my volunteer themer is starting from scratch with the aid of Bootstrap (http://twitter.github.com/bootstrap/).
It's still just a group of Features and not a distro and there's a ton to be done, but it's a spare-time endeavor and our sights were set too high at first. When theming is done, it'll be production-ready for smaller helpdesks. And we'll keep working on it; I'd love to eventually rival the quality of Kayako. Any help is appreciated, especially with figuring out how to implement the next-stage security model.
we'll have to package the
we'll have to package the theme in a way that can include the Twitter Bootstrap framework separately like an external library since it's apache3 licensing and not GPL2.
there are several ways to do this both on the theme layer and the module layer. the simplest way might be to modify the modules that features generates and plug it in there...