Reporting Issues

3 posts / 0 new
Last post
Reporting Issues

Hey everyone. I looked at the forum last weekend and realized that our TODO-List is constantly growing. I'm really afraid that, if we don't start organizing things a little bit, we will forget some of the items there - at least I will ;).

In order to keep track of our development activities, I think it would useful to introduce a new section on lqp2 where "Issues" can be reported and listed. Generally, I'm thinking here of something similar to the "Issue queue" which exists for pretty much every module or theme in drupal. (Here is the Issue queue for the Views module.)

Apart from development issues, we could also use this as a feedback channel for the "regular" users. There they could tell us where they see room for improvement and what future features they would like.

I think the following fields (and values) would be useful for the content type "Issue" in the case of our website project:




  • new
  • in process
  • in review
  • solved
  • postponed
  • closed (duplicate)
  • closed (won't fix)
  • closed (works as designed)


  • critical
  • high
  • medium
  • low


  • bug report
  • feature request
  • support request


  • code
  • user interface
  • documentation
  • miscellaneous

Assigned to

I guess the fields "Summary" and "Description" are self-explanatory. The fields "Priority", "Category" and "Component" provide a basic classification of the problem. The field "Assigned to" is filled with a user (with role administrator) which takes care of the issue.

The field "Status" is supposed to manage our workflow. Here I am thinking of the following sequence of statuses:


When we put all this data in a nice view with drill-down selectors like this one, we would have a good overview of what needs to be done and what we have done so far.

Most of these things can be realized pretty easily with the Fields and Views modules. For the workflow we would need a little bit more. We would basically need to restrict the possible values of the status field, when a certain value is already set (e.g. only "in process" can be selected after the status is "new"). I think for this feature we could use the Rules module.

So, do you think such an issue reporting system would be useful for the site or is it sort of "overkill" for this kind of project? Are there other features that you would include?

If we're gonna implement this, I think it would be a good idea to make up our mind about the fields and the entire workflow in detail before we start building the content type and and all this good stuff. Changing things afterwards is always a pain in the a** (e.g.: since a field of a content type cannot changed after it is created, we cannot add a status or component afterwards.).


This process looks very well

This process looks very well thought out - I think we can implement this using nodes and rules.

Since we will be dealing with the workflow ourselves, maybe indication via form_alter which option(s) should be picked next, according to the above diagram, will be sufficient.

On the other hand, there are also modules like "workflow" and "support" which seem to aim at providing something similar "out of the box".

I'm not such a big fan of

I'm not such a big fan of "out of the box" solutions - they never really fit to your actual needs 100% and you don't really know what's going on "under the hood" :).

Since the content type and the view are not such a big deal I would prefer building it from scratch. The module for the workflow could be quite useful actually.


Log in or register to post comments