That is a fantastic suggestion, actually. I resisted using categories (as we already use that field) or customization (for maintenance reasons), but I could certianly customize severity or priority. Thanks!
Now, just to get all of my users to agree on it...
From: Shawn Hill <email@example.com>
Sent: Thursday, February 12, 2009 3:34 PM
To: Help with Mantis <firstname.lastname@example.org>
Subject: Re: [mantisbt-help] Unique project names
I wonder if I can offer an alternative arrangement here?
We used to run multiple projects like this and it was an admin overhead at times. We then changed the severity enum string to have a 'feature' type. This allowed all the bugs to remain in the one project and can be filtered on easily enough. This is how we run it now across multiple products and it works well. Product Managers can see only the features if they wish and maintenance developers can see only the bugs if they wish.
I know this is not the answer you're looking for, but I thought I would offer what we do.
You may be able to adjust Mantis to allow non-unique Project names via a code change, but you will need to follow this change through on every upgrade you do. (like I have to with all my customizations)
On Fri, Feb 13, 2009 at 9:15 AM, Jennifer Mullen <email@example.com>
I have an example. I have several projects in Mantis. For various
On 2/12/09 12:06 PM, Gianluca Sforna wrote:
> On Thu, Feb 12, 2009 at 5:55 PM, Jon Hardcastle<firstname.lastname@example.org
>> > Can anyone shed any light on why sub-projects have to be unique over the
>> > whole of mantis?
> subprojects are really "projects", and you can't have two of them with
> the same name.
>> >This is causing us some problems as we have several quite
>> > level areas, then within this we have areas of responsibility and again
>> > within this categories.
>> > It is proving troublesome to have different names for the same things.. in
>> > slightly different areas.
> I am not sure I understand you here. maybe an example would be
> enlightening to make a more sensible comment.
reasons, some of the project managers prefer to have two subprojects:
one for bugs and one for feature requests. In other words, what they
want would look like this in the project selector:
Instead, what I have to do is this:
>> Bugs (Project A)
>> Enhancements (Project A)
>> Bugs (Project B)
>> Enhancements (Project B)
>> Bugs (Project C)
>> Enhancements (Project C)
If projects with identical names were allowed, then I could give my
users what they want, which is the first situation. I don't see a good
reason to not allow this since the project's name is not its identifier
in the database.