+1 on that. I see the rationale under the current approach, but a separate numbering per project is a must for our company.
--------------------------------------------------------------------------------
Please no.

The biggest reason to use Redmine is for multiple project management. This is the largest distinction between it and all the other issue management systems out there. It's already a pain that a lot of the stuff is still segregated into projects, especially versions and multiple issue editing.

Doing this would be the worst idea ever.
--------------------------------------------------------------------------------
> Doing this would be the worst idea ever.

Nobody is talking about *changing* the current logic. It suits well for many and nobody is arguing against that. There would be great to have an *additional* counter per project and a switch somewhere in the administrative UI which would change the URLs from /issue/12345 to /issue/project/123
--------------------------------------------------------------------------------
This would be very bad to do when people do cross project issue relations.

For example: Currently I can easily state ''issue #xyz is blocked by issue #zyx''. Once you know issue number, you know exactly which project it is for.

Similarly, I can have a commit ''references #cba'' and my commit will link across projects (with help from #3087 ).

If issue numbers are restarted per project then :
- can't merge two projects into one (since issue numbers will colide)
- can't move issue between projects (not without issue renumbering)
- can't link issues across projects (not without some funky #proj:issue funky addressing scheme)
- can't link revisions across projects (not without some funky #proj:issue funky addressing scheme)

Unless I am missing something?

Kind regards

Adam Żochowski
--------------------------------------------------------------------------------
> If issue numbers are restarted per project then :
> - can't merge two projects into one (since issue numbers will colide)

True.

> - can't move issue between projects (not without issue renumbering)

True. (The renumbering is an acceptable trade-off, though.)

> - can't link issues across projects (not without some funky #proj:issue funky addressing scheme)
> - can't link revisions across projects (not without some funky #proj:issue funky addressing scheme)

The #proj:issue addressing works just fine for these rare occasions. I am using it in our company's private bug tracker (which I've been writing in Django for 2 years).

>
> Unless I am missing something?
>

Adam, YES, I agree there ARE known problems with the local numbering. YES, that's easier to maintain a non changing global ID and that does allow a bunch of tricks involving cross-project operations. Still YES, what you are missing is that there IS a demand for local ticket numbers. There ARE people which can live with these inconveniences given that they can fully isolate different projects.

No offense. Should I have enough time, I would try to come up with a patch for Redmine. I discovered it a week ago and I'm eager to move towards it and probably contribute to the project.
--------------------------------------------------------------------------------
Doing this actually breaks functionality such as

* move the issue between projects
* using #issue number on an arbitrary wiki page or note!
* related issues now need to have related project - because multiple projects can have #10 issue no.

... just so many things in Redmine - because Redmine just have issues independent of most other stuff!

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,New,6642,anonymized issue numbers
relates,New,25625,Turn issue numbers into UUIDs