Ability to define own categories

Same here, I would love to add and change the values of the selectable categories on project by project base. same as the statuses or the components.

I would like to see this as well. The current category list, while good, is nowhere near complete enough for my needs. We need a custom list of categories, at least 10. We can make do with this for the moment, but I am bumping this up to 5.x-1.x-dev so it can be considered in the current project version.

Yes, this would be nice. However, it's lower priority for me than many other things, in particular:

http://drupal.org/node/18920 -- issue followups as real comments
http://drupal.org/node/76725 and http://drupal.org/node/76726 -- refactoring to using views
porting to D6 core
...

So, if this is going to happen anytime soon, someone else will have to supply the code.

Thanks,
-Derek

DWW, I see what you mean about the followups as comments. It seems to be a pretty serious issue, and when resolved, will fix a number of assorted issues.

As far as this issue here goes, for my current needs, I have simply replaced lines 1108-1113 with this code here:

    $categories = array('html-css' => t('html-css'), 'graphics' => t('graphics'), 'server' => t('server'), 'scoping' => t('scoping'), 'flash' => t('flash'));
  }
  else {
    $categories = array('html-css' => t('html-css'), 'graphics' => t('graphics'), 'server' => t('server'), 'scoping' => t('scoping'), 'flash' => t('flash'));
  }

then to fix the front page of the projects to compensate for the new types, I have replaced from line 346-358 with this code here:

    if ($view_issues) {
      $links[] = l(t('View all issues'), 'project/issues/'. $node->uri);
	  $links[] = l(t('View all HTML-CSS issues'), 'project/issues/'. $node->uri, null, 'categories=html-css&states=all', null);
      $links[] = l(t('View all Graphics issues'), 'project/issues/'. $node->uri, null, 'categories=graphics&states=all', null);
	  $links[] = l(t('View all Server issues'), 'project/issues/'. $node->uri, null, 'categories=server&states=all', null);
      $links[] = l(t('View all Scoping issues'), 'project/issues/'. $node->uri, null, 'categories=scoping&states=all', null);
      $links[] = l(t('View all Flash issues'), 'project/issues/'. $node->uri, null, 'categories=flash&states=all', null);
    }
    if ($make_issues) {
      $links[] = l(t('Add new HTML-CSS issue'), 'node/add/project_issue/'. $node->uri .'/html-css');
      $links[] = l(t('Add new Graphics issue'), 'node/add/project_issue/'. $node->uri .'/graphics');
      $links[] = l(t('Add new Server issue'), 'node/add/project_issue/'. $node->uri .'/server');
      $links[] = l(t('Add new Scoping issue'), 'node/add/project_issue/'. $node->uri .'/scoping');
      $links[] = l(t('Add new Flash issue'), 'node/add/project_issue/'. $node->uri .'/flash');
    }

Perhaps this can help someone else out. I'm still learning how to write modules that don't break Drupal, so until then, this hack will have to suffice.

I'm still in favor of making these customizable, but in your case, those look more like "Component" (which you can customize, per project, in fact), not "Category". Of course, all of this is somewhat arbitrary, but each of those things you've got there "html", "graphics", etc, are aspects of something that you might have bug reports against, features to request, tasks to perform, etc...

I'm looking forward for this improvement as well.

I'm marking this issue as postponed because I don't think this is a priority right now.

Also, once #76725: Refactor project issue module to use Views is completed, I believe that is should be possible to use the Comment Alter Taxonomy module (which isn't quite finished but is close) along with a small (custom?) module that added some glue code that implemented a few hooks. Alternately, this could potentially be done using CCK to handle the category field. I'm not sure whether either of these options would allow for upgrading of existing issues, however.

#405884: Customize Categories has been marked as a duplicate of this issue.

Subscribing, and voting up

This was driving me nuts, so I added a quick system variable to stick the categories in.

Note that this is *not* a robust or user-friendly solution. It just adds a box to the settings page for editing the global categories list. It does not provide project-by-project categories. (Though this should also be possible.) It will, however, work smoothly with existing issues and categories.

I'm dis-inclined to spend much more time on this, however, since as aclight mentions above, this seems likely to be replaced by a taxonomy or CCK field down the line.

(Make sure you run update.php after applying)

subscribe

Thanks!

#76725: Refactor project issue module to use Views has landed
Comment Alter Taxonomy is also in stable release

Is it possible to revisit this request?

Has there been any progress on this? It seems to me that using a vocabulary to define arbitrary categories as terms would be the way to go. I may have to add this for the company I work for, so I'm happy to work on this and provide a patch.

re-rolled the patch from #11 against 6.x-1.0-alpha5. Looks to work as advertised after some quick local testing. thanks!

I tried to apply the patch in #16 to 6.x-1.0-apha5 and got the following:

patch < define_own_categories_115553-16.patch
patching file admin.settings.inc
Hunk #1 FAILED at 73.
Hunk #2 FAILED at 132.
2 out of 2 hunks FAILED -- saving rejects to file admin.settings.inc.rej
patching file issue.inc
patching file project_issue.install

Can anyone please help? I don't know why that failed or what I can do about it.

Thanks,
-Dan

Just a quick note that the opened_vs_closed_by_category metric that we now provide depends on the static structure of the current categories for its underlying schema. if we are to make this configurable per project, it would become very difficult to continue providing this as a project issue metric, as the metric is collected across projects, and i believe collecting per project would be too inefficient.

if this was a global setting across all projects we could still provide this metric, with the caveat that if/when the global list was edited it would be necessary to adjust the metric schema or delete the old data and start collecting fresh with the new settings.