A complete solution for task/project/issue/case/ticket management with Drupal

mikey_p's picture

I've been evaluating solutions for Project management (for the duration of this post, that includes what i describe as project, issue, ticketing, case tracking, and pretty much anything that falls in that category) solutions with Drupal, over a year actually. I keep being enticed by the features of each individual solution, and new promises that are announced for each module(s) and trying them out and coming to the same conclusion with each of them. And yes, all of them seem to have the same problems that I'm hitting repeatedly.

They are designed with too specific a project system in mind, and are not ultimately extensible.

  • Project module and it's family are designed mainly to run drupal.org, and it does an amazing job at it. However project attributes are not easily modified or extended. I know that dww has taken on what is no doubtly the most crucial element to the entire Drupal project[1] with this module, and he has made amazing progress with it. However, one constraint to this awesome capability is that new and advanced features...no that's not right, dww and crew and getting tons of new features and such into project, the issue I'm noticing, is that features that wouldn't be used on d.o, are less likely to be committed. This is no fault against the project maintainers as they are already plenty busy, keeping up with the necessary features for d.o. Don't get me wrong here, Project* is amazing, and I'm grateful to the maintainers, however its very requirements but some limitations on it. (of course I know that I am welcome to submit patches to project*, but I fear that would just place added burden on the maintainers to review and commit them)
  • Enter Casetracker. It's newer and seems shiny and featured packed at first glance, but once again it ultimately fails in terms of extensibility and features. As in most cases of Drupal modules, it begins with a fairly specific task in mind, becomes more configurable, but ultimately doesn't give the user all the options they desire.
  • Taslklist and Tasklist advanced are another option, designed for more personal level. There's some good stuff in these, but they just aren't designed for the same type of collaborative uses, and extensibility that casetracker and project* are. And they suffer the same problems that project* and casetracker do as well.

My solution to this problem as I keep trying to write new glue-modules to tie functionality between all these, is that I need to just stop and rewrite the whole module from scratch to do what I need. This will solve all of these problems once and for all. At least as far as I'm concerned anyway. But surely, I've realized, someone must have had the same conclusions I did? And their module to solve all these problems would be different from mine wouldn't it? What do we do in Drupal when we start having several projects covering similar and duplicate functionality?

An API you say?

Enter the idea of what I have termed the TaskAPI (could just as easily be Project API, but that seemed to close to existing project*). Why not write a module that handles helper modules to assign project attributes to a node, and their display and then a module to display all that content different ways? Finally, extensible project/task management!

For the uninformed, I've just summed up CCK/Views rather well. They already do this. There is already an issue to convert Project* module to CCK and it's being written to use Views as we speak. So is that it? Can we already to everything we need with other Drupal modules? Pretty much. I'd even say for probably 80% of sites out there (maybe more) CCK/Views can do almost all of their custom content needs. So is that the end of the TaskAPI? I don't think so.

Actually I think it is still needed now, more than ever, as the glue between all these modules, and to provide the ability to hook, non-data, non-display task behavior to tasks through various means. I can't explain that very well at the moment, but I already have several use cases, that would not work well, with just CCK/Views. Also, some new field types/formatters may be needed, maybe not. I'm not even sure of all the functionality that the TaskAPI would provide, other than to be widely extensible.

So now that the idea is out there, I'd like thoughts and ideas on it. Specifically, what behavior would you add to CCK/Views to have your dream task manager? Is there interest in this type of project? Would anyone like to contribute? Finally, if this model proves to be successful, what would have to be done, in order to make it a central API to extending Drupal? Would project* or casetracker ever require the Task API?

Please note, that while currently no code exists in the repository, or my sandbox on this, that doesn't mean that it hasn't ever been attempted. This article is the summary of 3 attempts to provide the basic functionality described. Once, I tried hacking casetracker and organic groups to get the functionality I required, another time I built a site specific module to combine functionality which didn't really work. The last attempt, was a generic Casetracker/Organic Groups integration module, which I intended to release, but the features just weren't workable, without hacking Casetracker or Organic Groups. This time around, I'm trying to get input, and advice from the community, and I am trying to assess which current codebases could be workable to modify as well.

So let me know what you think!

[1] Without Project module and it's family of helpers, drupal.org wouldn't have an issue queue, and all development on Drupal itself would grind to a sudden halt.



DaveNotik's picture


I spawned Case Tracker, and I and the current maintainer(s) are probably in full agreement that we need to take this to the next level, towards greater flexibility.

Let's work together. I think your post, posing your challenge and thoughts to the community, is a great start.

I'll point some others to this post, let's perhaps turn this into some concrete todos for the Case Tracker module itself. CCK + Views is the right paradigm -- let's note any limitations, what it does not provide that a custom module can, and let's work to address those. Your thoughts?

You've got my support, I'll help any which way I can.



I'm glad casetracker is on board

mlncn's picture

and I would like us to work with project module to make sure anything that can benefit both projects, especially with a convergence on CCK and Views, does benefit both projects.

One feature Agaric would like is creating and posting follow-ups to issues by e-mail.

Mostly though we just need it to work-- Casetracker is buggy.

It's been asked on the issue queue with no answer that I caught– what's happening with Casetracker Extended?

benjamin, Agaric Design Collective

benjamin, agaric

Email followups

dww's picture

One feature Agaric would like is creating and posting follow-ups to issues by e-mail.

Me, too. As soon as the dust settles with D6 porting (maybe even sooner), I plan to dust off mailhandler support in project_issue. I'm hoping that now that followups are real comments, it should be even easier. mailhandler support once existed, but I doubt anyone's turned it on in ages.

crosspost this to projectmanagement group

yoroy's picture

The people in http://groups.drupal.org/projectManagement could provide you with good input I'd think.

I knew there were more groups...

mikey_p's picture

Thanks for that! I knew there had to be more groups for this, but I'm already a member of so many to start with, and my brief search, didn't turn this up, so I thought I'd at least post in Issue tracking to start with.

Agaric's current approach

mlncn's picture

is to throw our lot in with Project module.

Ways to help Project* modules

benjamin, Agaric Design Collective

benjamin, agaric

A potential solution for DrupalDojo2.0?

gusaus's picture

Looks like what y'all are discussing could be an ideal solution for the next version of drupaldojo.com (check the issues queue - http://drupal.org/node/202191) - possibly we could turn this into a dojo style interactive workshop?

Gus Austin
PepperAlley Productions

Gus Austin

Next steps

mikey_p's picture

I plan to create another page with more detailed information about what I think may be needed. I think alot of this is really going to amount to shakedown of CCK/Views features, (especially in regards to D6*). When I get all these thoughts together I think I'll start a planning wiki here, and maybe stake out a project on d.o, and start committing some initial code. Until then, keep the great ideas and suggestions coming such as email follow ups! Good stuff!


  • I don't see producing a Drupal 5 version of this project, unless their is sufficient interest, and funding. The drop may always be moving, but it really only moves one way ;)

Me too

ste5eu-gdo's picture

I've been looking at doing a similar thing. The issue I have with all of the current available modules is that they are missing something, and the only realistic way for me to change that would be to write a new module. The problem I have with CCK and Views is that I would like this functionality on multiple sites, and I can't see an easy way to package it, unless it's build as a module.


aexl's picture



emjayess's picture

Great minds.

I'll be brief by saying I concur with mikey_p and all the follow-ups, esp. ste5eu re: CCK/Views approach (admittedly I'm not very familiar with the Project* roadmap with respect to CCK/Views).

CCK/Views certainly deserves kudos and respect, but it's an abstraction layer, and when you are dealing with an abstraction layer you may get 80% to 95% of what you need, but closing the gap to 100% [of what you want/need] can be extremely painful, if it is even possible. Apply that principle to project management & developer workflows, which is naturally what we're focused on here, and it should be clear why it is so difficult to please everyone. No two toolboxes are alike!

I'm interested in contributing to this effort, where-ever it goes.

matt j. sorenson, g.d.o., d.o.

Voting system

mki's picture

Maybe some voting system will be useful. Users would vote on issue that they are recognizing as important. I think about something similar to http://www.ideastorm.com or http://brainstorm.ubuntu.com. Many times I saw 10 or more comments, that contain only: "+1" or "subscribing".

I agree

mikey_p's picture

I haven't fully fleshed this idea out yet, but imagine that with an extra twist. Users can rank sets of issues according to their value, and save that for their personal overview. (I.E. the the client's number one priority is X, but in my personal overview of the project tells me that Y needs done first, but I can sort the issues privately for myself, and choose to see that, or the clients desired priorities.)

Now imagine that you can 'share' your priorities, or sort of the issues. An advanced system could then aggregate the values of everyone that choose to sort and share their results.

You could also give a client a list of issue in the current milestone for example and ask them to sort them based on their priorities and then have them 'share' or 'publish' their sort/priorities so the rest of the team could review them, and build their personal priorities around the client priorities.

The overall idea is to combine the best concepts of agile software development and the getting things done philosophy as transparently as possible.

Of course that is all a plugin to the proposed idea of a general Task API.


catch's picture

Sounds like just what you want. Would just need per-user queues for it.

Voting API module

mki's picture

Great plan. Voting API module (http://drupal.org/node/68851) and many modules that using it seems to be good start point.

Possible example

roydean's picture

I have an option that may tie into this, however, this may not be the place to post - please advise.

The clients I service for computer support cannot afford to purchase issue tracking and hardware/software inventory applications so I looked for and found open source applications that are free and provide this functionality in a web application: ocsinventory and glpi at http://www.ocsinventory-ng.org/ and http://glpi-project.org/spip.php?lang=en respectively. These two apps work together to help an IT department manage computer and software inventory and they are extinsible I think, not being a developer I really should not comment about extensibility.

Anyway, my problem with both of these is that they have their own security and not being a developer I don't know how to make them use the drupal login mechanism, etc. I have made glpi work with Active Directory using LDAP functionality that I think is at the web server layer, but I am not real confident in my understanding to say for sure.

My question is whether these two systems' functionality could be "drupalized" or even integrated (mostly single sign-on gets access to each app) and whether their functionality is even the level that is being discussed.


jpetso's picture

This is getting very offtopic now, and has little to do with the original posting imho.
Anyways, you might suggest those projects to support OpenID, which will enable single sign-on for Drupal based sites and other ones as well.

Deleted: dupe

jpetso's picture

I'm really sure that I only pressed the submit button once.

My 2c :)

jeff h's picture

My 2c :)

Project * modules seem far too "hard-coded" (right now at least) to be well suited to a generic issue management system eg categories and priorities cannot be changed easily.

The casetracker modules seem to be the best option for those of us looking for a relatively generic, configurable solution.

However, it seems to me that casetracker isn't doing much that couldn't already be done using views/CCK/taxonomy in conjunction with a selection of other contrib modules such as subscriptions or workflow/actions. For example, the "Case states" really should be just three or more user-selected taxonomy vocabs, in my opinion.

The bottom line is, I feel that building my own issue tracker using views/CCK/taxonomy and perhaps organic groups will afford me the greatest degree of flexibility and customisability. So this is exactly what I have done. Yet here I am looking for a better solution, because as someone else has mentioned, you can only get the first ~90% of what you need, from out-of-the-box modules combinations.

An example of the 10% you can't get is: the project module allows a search on multiple terms in one go eg "active,fixed,postponed". To achieve this using taxonomy and exposed views filters can't be done without code.

I wonder if it would work better to move casetracker to a point of heavy dependence on and integration with views/CCK/taxonomy. Thus it would end up only providing that last 10% that we are all looking for and typically building into one-off custom modules.

Anyone else agree?

Project management for Drupal : my proposal

Roberto Gerola's picture

I've been working on a project management tool for Drupal in the past months / years.
I called it : STORM.
STORM runs on Drupal 6 and uses only Drupal core features.
It is yet under heavy development, but it is already in an usable status.

If you are interested, check it out here :
Some screenshots : http://www.speedtech.it/gallery/storm

Drop me an email if you want to try the online demo and I'll send you the details.



Links dont work...

D34dMan's picture

Roberto Gerola the links doesn't work.

And for those who want to check out the module, download and install from Drupal.org

Here is the link


Looks like Storm for D7 is

Circlefusion1's picture

Looks like Storm for D7 is nearly dead in the water according to this comment from the lead maintainer.

Some people in that discussion are suggesting a rewrite for Storm in Drupal 7 to use the Entities API.

Storm for D7 is not "dead in

juliangb's picture

Storm for D7 is not "dead in the water".

However, I am getting quite frustrated by the number of people that have not put any time into the development of Storm, but write issues demanding a release date. I should note, that there are on the other hand, some very helpful people who are offering help / have been helping on issues.

My message was trying to encourage more people to be described by the latter.

My site: http://julian.granger-bevan.me.
Maintainer of: Drupal PM (Project Management).
You can contribute towards my Drupal work at http://www.gittip.com/juliangb/.