Redmine

Without considering the possible side-effects of this change: I think I can appreciate it... :-)

Mischa.

Rob Elsner wrote:

We use Redmine where I work and had a need to add subcategories to categories for issue reporting. We used 0.7.3 and I'm working on a patch to add this to the subversion trunk (to get it so that we can update our redmine install). Would anyone be interested in this work? Is it something that would be a useful feature to include in Redmine for the future?

Mm. That's a feature I'd love to see as well.

Seconded (thirded after Mischa).

We are currently making do with creating lots of categories that have the same initial text, e.g.
Installation - Documentation
Installation - Common
Installation - ...

The disadvantage of this approach is that there are lots of them - a more hierarchical selection method might be easier to navigate.

A beautifully complete solution would provide a full tree structure and also allow selection of leaf nodes and certain branches (but maybe not all of them), e.g. could get rid of the 'Installation - Common' in the example above if the parent node 'Installation' was selectable too. I say 'certain branches' because I have seen situations where a parent node should not be selectable.

Cheers,
Jonathan.

Jonathan Monahan wrote:

I say 'certain branches' because I have seen situations where a parent node should not be selectable.

Hrm. I start to wonder about the complexities of this and if it's necessary. Could we just get away with a custom field for tickets called sub-category?

What I've added is a Subcategory that belongs to a parent category. The field is nullable, but the parent category must always be selected to select a subcategory. Jonathan's approach is close, but what I have isn't nearly that complex, it's merely an additional field that has a parent relation to IssueCategory. This was the simplest way we came up with to support the existing relationships without causing a huge data migration problem. Does that seem sufficient?

Yes, I agree my suggestion is complex - I did imply that it is the perfect solution - the world generally needs a pragmatic solution. The trouble is the simple solutions are often a bit restrictive. Yes, I agree that adding a single sub-category is much better than just one category level, but even two levels is often not enough in my experience; I've often seen situations that require 3 or 4 levels; where do you draw the line?

How about better-nested-set as a way of storing nested categories in one table. (As always, the storage and the algorithms are easy - it's the UI that's more difficult! ;-)

Me too, it's a feature I'd love to see !

I think the implementation need to take care of the futurs changes of Redmine to not make problems on next upgrades.
For example, a next version could may be permit to translate the Category in the different languages (we are french and we works with french & english clients, this could be usefull!).

• Don't need to update the administration page (or may be only to inform it's possible to make sub-category with the separator)
• Don't need to add a new fields in DB
• No risks for next Redmine upgrades
• Only require some JavaScript code on the ticket page to create on the fly the sub-categories nested lists and to back on the default "Category" when the user submit the form.
• Unlimited levels of categories

Here is how I propose to do it technically :

• Use the pipe | separator instead of the tiret - to not match some composed words expressions (eg: Back-Office)
• When the issue page is fully loaded, we run a special function for this task "enableSubCategories()" :
• We hide the current Category list (issue_category_id => display: none)
• We call the function createSubCategories(document.getElementById('issue_category_id')), this function will create a new list from the values found into the list set in parameter. This will only show the new list if there is sub-categories found in of course.

Then, when a user will choose an item, this will call the function createSubCategories(this).
So this will make the same as before, and permit to have unlimited sub-categories (eg: "Back-Office|Design|Users Area").

And on the "onSubmit" event, we call a "disableSubCategories()" function, to simply find the good value to set on the initial "issue_category_id" list ( we keep it hidden because if a required field of the form is empty the page will not be submitted ).

What do you think about that ?

Rob, are you ok to do it in this way ?

Guillaume,

The issue I see with your approach is enforcing rules like this in javascript (and covering it such that no-javascript presents a similar appearance, multiple layers of list boxes). Of course all of the details could be abstracted to the user to provide the appearance of endless subcategories, but it really isn't implemented. And there would be the issue of reporting, if you wanted to see all the issues assigned to a specific sub-category. Though that might be as simple as LIKE and a % after the last subcategory.

The migration to add a field that is optional and add the supporting elements for sub categories is trivial, and does not break any current interfaces. If categories are already specified, they just work and have empty subcategories.

I do like the multiple layers idea, and Jonathan raised a good point about levels. We've seen this be not enough with just one broad and one sub category.

I'm pretty open to re-working this and getting it submitted to redmine, but I would rather not be the one to dictate how it functions or is implemented, I'm just looking for ideas. And, of course, it'd be easiest if it fit in with what we've changed already to just get this far but some SQL to convert our DB to a new schema would be easy enough.

Would anyone have problems if I implemented it in this manner?

Rob

Hi Rob,

Do it like you want, if you have already created a large part of the code I understood.

My solution was only to simplify the code, nothing to code in Ruby, no new DB fields, only few JavaScript and so no risks for Redmine upgrades.

But, can you confirm me if they add on Redmine the support to translate Categories in different language, that will not break your feature ?

Thanks

I tried to do everything similar to the category already, I don't know what steps are involved in translating but I think it should be fine.

Here is my svn diff of the addition for subcategories. I will also create an issue and attach this patch, per the submission guidlines. This is up to date against trunk, revision 2399.

anybody knows if this feature has already been implemented (I'm using 0.7.3 and couldn't update to the latest stable version yet...)

sebastián scarano wrote:

anybody knows if this feature has already been implemented (I'm using 0.7.3 and couldn't update to the latest stable version yet...)

It's not implemented in the 0.8-stable branch nor the trunk at r2697...

What about adding a set of "name/value" pairs for each defect instead? Let the author select which names and which values apply to their defect. Maybe some names would be required. Here's an example:

Operating System: Windows XP
Environment: Production5
MustTellClients: True

Then, there might be other optional names that the author of the defect didn't select because they were not relevant like:
BrowserFlavor
SmartClientVersion
SchemaVersion

So we've been using the patch I submitted for a while, it works but it could be better. I've read quite a few of the ideas above, does anyone have a concencus on what/how this should be implemented? I can re-create the work if we get an agreement of what.