I've been quite successful in implementing a project management site to track issues and time spent using TTW dev tools, namely CCK, Views and Workflow.
Some key pieces of the recipe:
There are three content types: Project, Ticket, and Work Log Entry.
- Projects have a multiselect "Team Members" user reference field.
- Tickets are associated with a project via a node ref field.
- Work Log Entries are associated with a project and optionally one or more tickets via node refs.
Workflow is used to send email notifications on state change. The states are "Open", "In Progress", "Closed", "Deferred". The only missing feature here is a log field for recording the reason for each state change, to be used in the email notifications and elsewhere. See http://drupal.org/node/57905 for a patch which is beginning to address this need.
Oh, and of course views are used throughout to provide lists of nodes. In particular, the project type is themed via a node-content-project.tpl.php to provide a view showing tickets associated with the project. This view is of course filterable.
The site isn't live yet, but I will post a URL when it's ready.
Eric
Comments
JonBob was working on something similar
JonBob (of CCK fame) was working on something similar. i just happened to be in IRC when he mentioned it in passing. he's playing tricks with the node revisions to keep track of the log of changes. perhaps he can comment or post code somewhere for you to see what he's doing.
so, looks like we're up to (at least) 4 different forked implementations of problem tracking in drupal. oh joy. ;) so much for "drupal's great because it provides a single, unified interface into all of your content"... unless of course the content is problem tracking, and then there are 4 different, incompatible ways to handle it, each with its own strengths and weaknesses, none of which actually do everything you need. ;) at least we've got a means to discuss this stuff and figure out how we can unify in the long run (if that's even a desirable goal)...
Be happy
There are NO good ticketing/issue tracking systems out there. They all suck to some degree, whether open source or proprietary. As far as I can make out, this is because of the varying needs that people have, as well as the different data models / conceptual mind sets that such systems set out with.
So, ultimately, these things need to be flexible, so people can implement a workflow and associated features that work for them.
True, but I do think that
True, but I do think that these various efforts could be collaborating more effectively. This group is a good start. I'm the one fueling Case Tracker's development, so I'm just as guilty, but I want to take steps to ensure our pursuits are as open as possible. We're actually very interested in the approach edrex outlined, and we're starting to look in that direction.
I believe that part of the redundancy issue is that application development in general needs to become more modular, more of a common framework -- I'll say it here again: applications are really a set of custom fields (CCK), displayed in a particular way (Views) with certain associated actions (Actions? Workflow?). One day...
Let's keep this thread going... I'll report back on our own efforts.
--
http://www.woven.org
http://www.davidnotik.com
I've transferred a snapshot
I've transferred a snapshot from my laptop to http://projects.oheric.com for all to play with. You can create projects and tickets (woohoo).
This approach isn't yet 100% functional, primarily because development of actions and workflow has been postponed. It is my assumption that the Joh?ns are holding off on this in order to keep CCK pure and clean for inclusion in core.
Specifically, for project management I would like to be able to send email notifications on wf state change to users referenced by specific fields of the ticket (assigned to). Right now I can send notifications to node author, but there are no other mechanisms for dynamic user selection.
I'm experimenting with cck primarily to collect requirements for future TTW dev tools. I would like an "actions" capability which responds in a flexible way to node field updates by triggering actions, the parameters of which may be derived from other node fields. These actions may be internal (modify other node fields), or external (send emails etc).
This capability depends crucially on node validation. For simplicity, lets consider this as a CCK-only feature (everything will be CCK, right). I would like to be able to attach multiple validators to a cck field. If this were implemented, it would be a simple matter to respond to the return value of a validator by triggering an action, rather than allowing/denying the node add/update form submit.
Just some brainstorming, on top of 4 happy hour pabst tall boys and a pixies marathon on the jukebox.
E.
eating our own dog food
boris, very true. there's no way 1 single issue tracking system can solve everyone's needs. what you say is totally right. i'm all for more flexbility, and CCK rocks. if you haven't already noticed, i think all event management stuff (including the signup module which i now maintain) should be thrown out in favor of using CCK with node-relationship fields. i certainly wouldn't want to advocate halting effort on similar ways to solve the issue tracking problem. this stuff is clearly the "R+D" lab for the future, and we absolutely must spend some time in the lab, figuring out new ways to deal with these problems.
that said... ;)
i'm just coming at this from the slightly bitter point of view that the project.module, for better or for worse, is the fundamental module that sits on top of drupal core to make drupal.org (and therefore drupal itself) possible. it's how we deal with the software development process for our entire system. i'm feeling a little embattled, like i'm the only one who actually cares enough when it's broken to stay up until 3:30am to make sure killes updates the copy on drupal.org with the fixes i made that night. ;) i'd very much appreciate more effort from the (currently 59) subscribers to this group to help debug, review, test and fix the thing that manages all of our software development (from CVS access control, to issue tracking, to making the release tarballs). i know we're all busy, and we're all doing good things. but i still can't believe previewing issue followups stayed broken for something like 2 months since i couldn't find anyone else to review the patch (which wasn't perfect, and needed a few changes in the end). ;) either i'd like to see more help in this effort, and/or all the people with money floating around to sponsor drupal development should start sending me checks, too. ;) maybe there should be a project.module "tax" on all drupal-sponsored work that ends up in the contrib repository... (yes, it's nearly 4am and i'm mostly out of my mind at this point, but i think i'm only mostly joking about that). ;)
ITIL ?
Maybe, just maybe, having a long look at ITIL could help avoid some mistakes in that regard ?
After all, it's supposed to condense best current practices in the field.
process / tooling
indeed can itil do wonders for your maintance of it, it is a process instead of tool. in the netherlands (where my employer is itil king :-) and euope itil is /the/ standard for over a decade, in the us it is gaining ground from what i understood.
--
bert boerland
--
bert boerland
i officially endorse
i officially endorse coordination of issue tracking modules/efforts around a single API/module based on an ITIL standard.
agree... but reinventing the wheels ?
this includes what I've seen in the CCK based PM...
it's nice and looks pretty much like a little content workflow I implented just 2 days ago with
workflow_actions, ng_arbitratror et.al
(see: http://www.angrydonuts.com/publishing_articles_a_tutorial for docs and the bug
I had to fix to make it work here http://drupal.org/node/72200)
however the main issues of
I'd love to have a good drupal tracker, but I currently wonder if so much man and brain-power should go towards reinventing the wheels of BugZilla, Jira, and all those other top-notch software-tracking/release managers... (not to mention big asset management tools..)
best regards
Christoph C. Cemper
http://www.marketingfan.com
http://www.cemper.com
Christoph C. Cemper
http://www.marketingfan.com
http://www.cemper.com
please do share
it would be terrific if you could post that url, and even give some trusted people admin access to see your CCK config. I'm certainly interested, and so will be JonBob and dww.
workflow patch committed
i asked JVD to review that workflow patch and he did so immediately. It has been committed. I look forward to more progress on this solution. We've still not arrived at the ideal ticketing system, and it makes complete sense to me to have multiple independant efforts during these nascent times.
The patch made it in
The patch made it in yesterday (yay!)
I pretty much gave the whole
I pretty much gave the whole recipe, anyone can easily set this up.
Bits of code which are needed:
<
ul>
</ul
This cck view field thing is a hack, but useful atm.
I'll set up a public test site shortly.
Thank you
Hey edrex:
Thanks for keeping this group informed of your efforts.
How do I get into the site? Didn't take my @drupal.org login, /user giving an error.
--D
[Edit] (Sorry, this was supposed to get filed under http://groups.drupal.org/node/409#comment-1343 -- actually logged in in-between, so maybe didn't preserve that I was replying to that post.)
--
http://www.woven.org
http://www.davidnotik.com
posted the wrong url
posted the wrong url initially. http://projects.oheric.com is correct. I'll enable drupal.module for dist auth.
Still haven't received
Still haven't received e-mail w/ password for new account.
--
http://www.woven.org
http://www.davidnotik.com
Drupal.module is enabled -
Drupal.module is enabled - just login w/drupal.org ID
Some points
Yea, I had got in that way. Thanks.
Really interesting stuff. A few points:
It appears one uses the Edit tab to change fields for a particular ticket, and Workflow tracks state changes. With Case Tracker, we utilized a different flow (similar to project.module) which lets you change the states while adding a comment, which seems more intuitive to me. We track the changes via a snippet of text that gets added to the comment string (bug --> feature request), which also seems more intuitve, though not as comprehensive (and scalable) as Workflow. I also proposed a core feature that would let a site admin change the comment display per node type so that comments on cases can be flat, but nested on other types (http://drupal.org/node/56292 -- show your support!). Can the CCK/Views/Workflow scenario support a flow like that?
I like how you can choose who's on your project team. I assume it could just as easily be an auto-complete field that lets you type the e-mail addresses or usernames, and I guess an invite feature can be added to invite others to the project later (in your demo, you can do this on the Edit tab).
What about a cleaner view of tickets, with filtering abilities (only bugs, only critical)?
What about e-mail notifications?
Overall, alot of the functionality is there, it just needs a smoother interface.
And by the way, what is TTW?
Great stuff -- I'm closely watching this. We're actually building View support into Case Tracker so we're definitely moving this direction.
--D
--
http://www.woven.org
http://www.davidnotik.com
Thanks Dave for taking a
Thanks Dave for taking a look.
Regarding comments VS edit tab for changing ticket state: In my dev copy I've enabled merlin's workflow tab, which gives a tabular log of workflow events and their log entries. It would be possible to render workflow events below the node similar to comments, although they wouldn't be threaded. This isn't meant as a "real world" application, but as a test case for emerging APIs, however, so I'm more concerned with improving these APIs than with improving the application.
Using comments to trigger workflow transitions is an interesting possibility, one that should be considered in developing the functionality which will replace workflow module.
I have a patch in to restrict the allowable values for user reference fields by role: http://drupal.org/node/62503 .
Ticket filtering is trivial.
Email notifications aren't fully functional: I need to be able to send email to users referenced by specific user reference fields in the node. I can notify author, but not team members or users assigned to. I may write a bit of glue to make this work, but again, I'd like to help to improve the apis.
This is my second build of this type of site, and I've put off some of the features that were easy to implement the first time.
The public site is a snapshot of the copy on my laptop (so don't put too much effort into making test data). With the next snap, I will start using the public site for development so that contributions won't be lost.
TTW (through the web) is a TLA I picked up somewhere, which captures nicely the emerging philosophy within the community of application development detached from the filesystem.
I'm planning to look at ways in which Organic Groups might be able to augment this approach for the projects test. I've never worked with this module, so input is welcome.
Some leftovers from my last
Some leftovers from my last post:
Node Interfaces
It is a general problem in Drupal to provide custom view/edit interfaces to nodes. These flexible interfaces could replace the default view/edit tabs, following the emerging philosophy of TTW (Through The Web) development within the community. Access to each interface could be restricted, eliminating the need for field-level access control.
The edit problem is in some ways distinct from the view problem, but there may be advantages to implementing together.
A somewhat related problem is that of providing a TTW interface for specifying conditions under which a node update will trigger an action. Each "trigger" would probably be attached to a node type. Example:
If the node body is modified by role "role" and the field "state" is set to "published", set "state" to "pending" and unpublish the node.
It should also be possible to reject the update (user specified multi-field validation conditions) and specify a validation error message to the user.
Grouping/Filtering Nodes
Another general problem is grouping or filtering nodes. This corresponds to the "WHERE" clause in the node select statement.
These two major problems are tackled simultaneously by views module. For inclusion in core, they should be addressed seperately. A generic, clean solution to these two problems would greatly reduce the need for third party modules.
error on creating a ticket
user warning: Duplicate entry '17' for key 1 query: INSERT INTO node_content_ticket (field_type_value, vid, nid, delta) VALUES ('Bug', 17, 17, 0) in /www/projects.oheric.com/public/includes/database.mysql.inc on line 120.
Your project tracking system looks cool. I wish there were an API for CCK & workflow so you could package this up into a madule.
thought-provoking
All very interesting (thanks dww for pointing me to this group).
Yes, I use CCK a bit, and I'm sure it's working well in this example. But I find CCK to be a little too generic for this type of thing. IMO you can't have 3 different content types working together smoothly without using extra contribs and additional code (eg. form_alters) to improve the user experience and minimize the user's time spent in the system.
To illustrate my point, I once created a basic media content page using upload.module and CCK. This worked fine, but to improve the efficiency and user-friendliness of the edit form, I had to do some form_alter() -- as soon as that happens I'm forking and developing internal IP and losing the collaborative advantage of a Drupal project. I can provide a usability patch to casetracker, but not a kooky context-sensitive form_alter patch to CCK. Horses for courses.
I suppose I liken CCK to another component-based product like an IKEA wardrobe. You can mix and match and it comes in a flat-pack, but it still looks like a laminated allen-key built wardrobe. If you want the custom built wardrobe, it's more expensive, harder to move, but looks good and works seamlessly.
So, while there are aspects of casetracker that are not working 100% as I'd like, this is a fairly long-term thing for me - probably only 1 installation for the life of my business, and contributing to the custom furniture is my preferred route.
@dww. Yeah, I think a number of different strategies are inevitable for project/case management. I use casetracker because it's specifically not for managing software development/releases - therefore it's philosophy matches my long-term needs. Sorry, this doesn't help you get collaboration/testing on project.module :-/
.s
Subscribing... Is there any
Subscribing...
Is there any chance that this discussion will pick up again...? :)