Redmine

• there is lot of "global views", like show all my tickets in all procets
• issue number itself is absolut and unique identifier, you don't need to have to parametrs (now you can write just: do ticket #123 instead od ticket #123 from procejt #45
• issues can be moved between projects/trackers while keeping their numbers (very usefull when mergin two smaller projects into one, or splitting one procets into smaller ones).
• integration with other sw is much easier, because issue id can be unique key just alone
• simplified url construction of global (non per-project) urls

Regarding "running out of tickets numers": we have over 100 projects in our company and everything works just great. There are really huge projects like SourceForge, which have thousands of projects and users and there is also unique global isue numbering and it works without problems.

Only one problem can be relatively high issue numbers, but it's only one drawback I can see (and unimportant one).

Hi,

Me also having this same issue. In my case I have different clients working on different projects which is getting svn hookup scripts automatically generated based on a continuous issue id. If there is any work around for getting a unique issue id for each project kindly let me know . Everything else in redmine is working perfectly fine.

Thanks
Tom

My urgency+curiosity forces me to ask a question, whether something can be done within the database (some where in the "issue" table "project_id" or "issue_id" fields) . This would be really great to serve the feature completion of multiple projects (isolated as well as interlinked projects) . Really looking forward for some guidance.

Thanks
Tom

AMHO, it's a big yard but it have to be done:

Redmine should by default propose a global issue identifier as it's currently the case (this, for little structures) but propose an admin option to switch to a JIRA still identifier: project shortname + local issue identifier. But once in "JIRA style" identifier and a new issue created, switching again to default style should be prohibited.

That'd add a non-negligible layer of complexity in every usage of issue reference in redmine, so it's a big big big yard. Maybe for 0.8?

I don't really see this as an issue that needs fixing at all.

Debian, for instance, has a global bug number for all its thousands of projects. We're at around 400,000 bugs now. We're not even close to approaching the limits of a 32-bit integer, and we've been going for more than 10 years. And Redmine isn't targeted at something the scale of Debian.

I don't think it's worth the complexity of supporting two systems. I like it the way it is.

I just would like to be one more voice saying that there are so many reasons why per-project issue numbers are much, much better:

• much better understandable "global views" - can see on issue-id easily to which project issue belongs
• especially issues with global issue view sorting will be no issues anymore :)
• using a global counter for unique issue identifier always needs something to identify the project beeing talked or written about - just writing about "issue 23" is not enough in multi-project environments, you will always need to tell "issue 23 in project x" in project communication anyway - so why not just do it with "issue proect01-01", what reduces the amount of meta-information needed within communication - mind that there might be more than only one instance of redmine or a project tracker in an organisation, hey, that is another point...
• the weakness of the current issue numbering scheme complicates communication with multiple-instances of redmine - this proves the misconception of "issue 23" beeing enough as a global identifier - your world must consist of only one redmine instance, to have that concept working - but the world is bigger. So you will need "project-issue-nr" always and everywhere in the long run.
• Issues must not keep their numbers if moved between trackers or projects - it leads to very confusing situations, e.g. when there will be an issue "3" after issue "50" if not renamed into a project specific issue numbering. Of course you still want redirects from the old issue identifier to the new one.
• integration with other software is much easier, because with a identifier like "project-issue" you really need only one db-field to have a globally unique identifier for one issue - with only the issue-number you will always need another identifier that tells people or software from outside to which project the number is connected to, what makes integration more complicated.
• simplified global urls that make it clear on first glance to which project an issue is connected
• it is much better for multi-tracker installations with many unrelated projects.
• you will receive much less support requests from users wondering why their issues are numbered "wrong".
• it is generally bad when software limits your possibilities and does not give you options to choose from and to do it the way you think is the right way to do it.

really, this should definitely be mentioned in the features list, I would have saved a lot of time with knowing this before - i must admit that it did not come to my mind that such a serious restriction could ever exist in a bug tracking software that received so many rave reviews - shows one more time, that you can not give a dime on what other people are saying is good or not good.

BTW it is totally ok for me if other people or projects feel good with just a simple number as a global issue identifier, however it does not change the way I think about it - what others are doing is a totally irrelevant argument in this discussion. It is always good to stay open-minded to check how other projects are doing things, but it is also good to use your own head. Many people doing things is never an argument things are done right that way - this was many times proved with political elections :)

Besides the fact that there are ways to get around that limitation and to just live with it, it is still exactly this: a limitation.

So one vote up for per-project issue numbers!

Snaky

Please note: I do NOT think that Redmine is not good - one part of my text above reads a little bit unappreciative - on contrary I think it is good - because it is easy to understand and usable not only by developers, what makes it easy to integrate / invite non-developers into work processes. That is why I take the time to support a request for a really global issue identifier! If I did not like it I would not spend one more minute with redmine. But having some more options with redmine would make it even better! So please do not read my previous text as an annoyed rant but as engaged criticism :)
Thanks again for your attention!
Snaky

There should be an ability to make issue numbers unique within a project and/or there should be an ability to export a project from one host to another Redmine host that is already up and running (and therefore in which there may be global issue number conflicts).
Rational: Many software houses are required to provide all the software (including source code, documents, development notes etc) as part of their contract. For example it is usually the case that all software (source, documents etc) is deliverable when working either directly or indirectly for the US government, as covered by various DFAR notices.
So how then would you deliver a particular Redmine project as part of a delivery? How would you avoid issue number conflicts when the purchaser imports your database?

I too think that Redmine is a wonderful tool. It was my belief that Redmine provided all the feature that I needed.
This 'issue' however has knocked my belief badly, without a work around I can no longer recommend this tool for all uses and in particular I cannot recommend the tool for commercial use; the tool ultimately lacks the end customer focus too conveniently deliver and accept delivery.
This limitation has me looking for a work around or ultimately another tool. I, like many, only time to learn and configure one tool and therefore this limitation may prevent me (and likely many others) from adopting and promoting Redmine, which would be a real shame.
I would love to be proved wrong with a work around and/or the correct way to configure as otherwise I'm a fan!