What is the proper way to model software components in Redmine
We are about to migrate to Redmine from a bunch of other systems, one of them an issue tracker. We are wondering how we should model discrete components of our applications in the Redmine issue tracker. Each of our project has components and usually a person or group of people works on one component. We would like to log issues against specific components, and then have the issues assigned to the people assigned to the component.
One way to do it is with custom list fields where we record the components as list values so issue reporters must pick from the list. Works well but since the system doesn't know anything about the meaning of this field, there is not much added value, for example we still have to assign a person to the issue even though an initial person selection could be done through the component.
Another way we see is to create subprojects for each component, but when we tried that, it seemed rather heavy-weight and the wrong way to approach this. For example I had to re-add all people who were already members of the parent project again to the subproject. Doing this lots of times for lots of subprojects isn't fun.
It seems to me that Redmine could benefit from the concept of such components in its core model. Is something like this planned, or are there other ways to do this that I have overlooked?
RE: What is the proper way to model software components in Redmine - Added by Marc Spitzer about 14 years ago
within a given project gp tp settings->issue catagories and then make a catagory for each item you want to track.
RE: What is the proper way to model software components in Redmine - Added by Marc Liyanage about 14 years ago
Thanks Marc, I have no idea why I didn't see that :-)