I'll consider it but it won't be for a while.

Hey, this feature would be great.

ddegraff

Why not settle for unlimited nesting of categories, instead of only 1 or 2 levels? Thereby it's up to users how they'll divide and categorize their projects.

"Report-bug": Category dropdown show indented tree-like view of categories.
"View bugs"-page: display only last category, optional category path / hierarchy like cat1/subcat 2/subcat 2.1

I think 2 categories are more than enough, if not too much overhead already. Imagine the common QA employee dangling through that complicated drop-down list containing 10 nested category levels. They will never use the thing again but rather call you up. It's just a usability thing.

(Please see my other comment about usability in 0001144.)

Would using this type of setup work for you? Here's a list of categories:

Category 1
Category 1 - Sub 1
Category 1 - Sub 2
Category 2
Category 2 - Sub 1
Category 2 - Sub 2

The categories get a bit long, but they are sort/filterable (well, can't do cat 1*, but you get the idea), it is flexible, etc. If that wouldn't work, why not?

This is the way I do it. But you know... they're so long that are names that get "cutted".

Anyway, there are other problems, as for example, I want that summary graphs
show result values for categories (as they do it now), but I want sub-categories for organization.

For example:
bugtracker
|- search bugs
- add bugs

In my situation this would be more (much more) usefull.
Anyway, would be a great feature for bugs organization!!!

I'm for this. I actually had to turn the categories into self sub categories so they would be grouped in the list like : "Application - software - something", or "'Site Name' - 'hostname' - 'ip address'". So subsequent similar entries would be grouped so you could easily find what your looking for but it would be REALLY nice to have auto-populated drop downs for the sub categories.

On the graphs, I just went in and edited the graph sizes because with so many categories the text looks like jumbled so I expanded the text area and the graph size and it works. It would be nice that the graphs auto sized or a way to edit them on screen. I opened another feature request for this.

Yes, sub-categories would be extremely useful.

The workaround like :
cat1 - sub1
cat1 - sub2
cat2 - sub1
...
doesn't work for me anymore - I just have too much sub-categories.
And I thing that 2 levels of nesting could be insufficient.

This would be great! Especially for BIG systems. IE:

"A System"
"Security"
"Server"
"Desktop"
"A Related Project System"
"Sub-System"
"Bug"
"DB Issues"

etc etc

The "workaround" for "CAT1 - Sub1" wouldn't work for me bit of a pain if you have loads

Here is my vote; good suggestion, could realy use this.
Already asked for this in the forum http://forums.mantisbugtracker.com/viewtopic.php?t=2243&highlight=
although there I mentioned doing this with a custum-field.

Here is my vote; good suggestion, could realy use this.
Already asked for this in the forum http://forums.mantisbugtracker.com/viewtopic.php?t=2243&highlight=
although there I mentioned doing this with a custum-field.

On my mantis server, I have implemented nested subcategories. The database and internal storage and configuration remains the same. I've simply created a new self-contained function:

# sjbuehler --- Then we display the categories as a collapsable tree list instead of an option list
function print_category_tree_list( $p_category='', $p_project_id = null )

which, when used in place of print_category_option_list(), displays the categories as an expandable/collapsible tree up to an infinite number of levels deep. The only requirement for the nesting to work is that the categories must be named as if they were paths, e.g., Category, Category/Subcategory, Category/Subcategory/Sub-subcategory, etc.

Since the categories are stored internally the same way, the summaries and whatnot still work. The only change is on the bug reporting pages, or wherever print_category_tree_list() is used in place of print_category_option_list().

EDIT (dregad): fixed markdown

to sjbuehler:

your solution looks like a simple and effective approach. Are you willing to submit a patch with your implementation? if so, please try to follow this guidelines:

http://www.mantisbt.org/wiki/doku.php/mantisbt:howto_submit_patches

thanks in advance

Is there a chance that it will be submited ?

Yes, I'm willing to submit a patch. Unfortunately, I'm extremely busy right now and it may have to wait until after Thanksgiving. (If I find the time to get to it this weekend, then I will; no promises.)

By the way, my implementation of nested categories has been modified so that, in addition to collapsible trees, it can alternatively render as multiple appearing/disappearing drop-down boxes containing data that depend on the selection of the previous (parent) drop-down box(es).

(Sorry for the multiple edits.)

I think it would be best for you to hold off on this patch. I'm very close to finalizing an ID-based category system for Mantis, which will certainly break your changes. See bug 0008435 for more details.

@sjbuehler - would you be willing/able to provide a patch for this against trunk, which has the new category system fully in place? Cheers.

Without a patch, this is dead in the water. It's been five months...