Redmine

Maybe it would take a little more time to develop cause I haven't taken into account links to issues in textfields. # + issue number would not suffice anymore, except when the project identifier would be integrated with the id (or only using that syntax when linking in the textfield)

How do you link issues between projects? (aka: issue # 35 from project A blocks issue # 35 from project B)
How do you link issues in messages?
How do you move an issue? (aka: issue#35 is moved from project A into project B)
How do you link commit messages to issues (especially with #3087 a commit to project A can close a ticket in parent/child project B, how does one handle this message?)

It is simplest to keep the issue numbers as they are.

Kind regards

Adam Żochowski

Adam Piotr Żochowski wrote:

How do you link issues between projects? (aka: issue # 35 from project A blocks issue # 35 from project B)
How do you link issues in messages?

Like I said, we would need to rethink that. It is possible (JIRA does it as well using a project prefix and number, e.g. RAN-34 and RED-34) by just adding more information. For example, linking could be done this way for project A: #35-A and for B: #35-B.

How do you move an issue? (aka: issue#35 is moved from project A into project B)

If you move an issue to a project where its number is already taken, then you just take the highest number used + 1. So issue 35 in project A could become issue 63 in project B.

How do you link commit messages to issues (especially with #3087 a commit to project A can close a ticket in parent/child project B, how does one handle this message?)

Same syntax as with messages (see above).

It is simplest to keep the issue numbers as they are.

Yeah it would probably be simpler to develop as it is now, but towards an end-user experience I think my proposision (the JIRA way) is better. In our company we have more then 20 projects with every project more then 500 issues (stories, bugs, features, support, ...) so it is easy to have issue numbers like 10943 and this just seems messier and more difficult to remember then 35-RED.

Just my two cents.

Thanks for sharing your vision!

Mano Swerts

Jean-Philippe Lang wrote:

This was already discussed in #282, #538, #1926.
Using such identifiers when you can move issues is too problematic.

It sure is more difficult to implement then what is implemented now, but I don't think that it is that problematic when it is programmed well. And, in my honest opinion, I do not see the need for moving issues between projects. Projects are all very different to each other so the chance that you will want to move an issue for one project to another is fairly small.

And, in my honest opinion, I do not see the need for moving issues between projects. Projects are all very different to each other so the chance that you will want to move an issue for one project to another is fairly small.

I disagree. I move at least 3 issues every day; either they are entered on the wrong project or after a discussion it's decided that the issue should be filed somewhere else.

I agree with the won't fix resolution.

I agree too with this resolution.
But described functionality (additional issue project-related numeration) might be implemented by plugin.

Eric Davis wrote:

I agree with the won't fix resolution.

+1

I agree with this behavior now, (because the number is really not important, especially for #3843 or more big number, and I also move some issues between projects.) but at the first sight, i feel strange with it.

anyway, the only bad time is when I communicate with customer. they also confuse with this hopping number and issue #47 of 35 issues, and I do not want to manage map of redmine#47-to-customer#26. so I think, at least for some cases, we need both issue_id(for system) and issue_num(for communication). one existing solution is using custom integer field. but it's very annoying and there is no option like auto-increasing.

how about your side?

To me, the original reason for this issue is not of concern, however, there are at least two use-cases that per-project issue numbers would help with:

1. Importing from other issue tracking systems. The original issue numbers could be preserved because the imported project is its own new thing.
2. It would allow Redmine to have a capability for exporting and importing projects. Say, to move a project from one installation to another, or to mothball a project to DVD and keep the ability to un-mothball it years later without conflict.

These are both features I would find useful...

Eric Hulser: I also agree with others who want to retain the ability to move issues without them changing their identity. In my organization we use hierarchical project structures, and frequently move issues between sub-projects of an overarching project.

So.. I want it both ways -- not sure what the "real" solution should be. :/

How about giving issue aliases? I agree with all the benefits of a unique issue id. Yes it helps in many ways. To get the best of both world, we can retain the unique issue identifiers and provide a issue alias. So a issue #3843 can be referred also as #REDMINE-xyz something like JIRA does. Have a look at the Apache issue tracker

I implemented the "another option", but instead of the project identifier I used the special project key. See this page.