Defect #74

Projects share issue numbers

Added by Marcin Gil over 10 years ago. Updated over 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution: Affected version:

Description

I've created two projects within one RedMine installation.
To my surprise when I created a new issue for new project the issue number was subsequent to last issue number in other
project.

I think that this behavior is wrong and issue numbers should be separate among projects.


Related issues

Related to Redmine - Feature #6642: anonymized issue numbers New 2010-10-12
Related to Redmine - Feature #538: Issue Numbering is note respecting projects Closed
Related to Redmine - Defect #2004: Trac Migration ticket numbers vs. global Issue numbers Needs feedback 2008-10-07

History

#1 Updated by Marcin Gil over 10 years ago

Would it be possible to use some project_id + number as
issue_id?

If one gets a single number for issue, like #153, one
doesn't know what project it references to until one looks
into the system. Also I haven't met any situation when one
would need to move issues between projects.

It's a little bit odd to have project A to F, and when in F
I have 3 issues numbered 1-3 and in A-E 100 issues, then the
next number is 101 in F.

#2 Updated by Jean-Philippe Lang over 10 years ago

Hi,
It's not a bug. It's easier to reference an issue with a single
number. Issues can also be moved from a project to another.

#3 Updated by Esteban Alvarado about 8 years ago

I think it's really annoying to find out that identifiers are shared among DIFFERENT projects.
I have spent my time setting up redmine for my organization, everybody was very exited about the application, but when they found this behavior they discarded redmine because of the ISO 9001 tracking requirements.
I do love Redmine, and I think separated issue numbers could be an important improvement.
Thanks.

#4 Updated by Esteban Alvarado about 8 years ago

I think it could be related to issue #2004

#5 Updated by Adam Piotr Żochowski about 8 years ago

Esteban Alvarado wrote:

I have spent my time setting up redmine for my organization, everybody was very exited about the application, but when they found this behavior they discarded redmine because of the ISO 9001 tracking requirements.

Which section of ISO 9001 requires that each support-ticket/issue-number must be exactly one number from previous number? I could be wrong, so far I went through ITIL foundation and it was not that specific.

I do love Redmine, and I think separated issue numbers could be an important improvement.

Please see previous discussions : #282 , #538 , #1926 , #3843

Kind regards

Adam Piotr Żochowski

#6 Updated by Rick Nixon over 7 years ago

Yes, this is really annoying. Should you set up multiple projects and only begin populating issue slips to one project, the slip numbers are sequenced and offset by the number of projects you have set up. For example, I set up 5 projects, and began filing issues on only one of the projects (the 3rd one set up); the issue numbers in sequence of filing are #3, #9, #15, #21...

If the other projects were active, I understand the logic behind non-sequential incrementing of the numbers to guarantee unique identifiers across all projects. But to reserve "slices" of integers based on the number of projects? Sigh.

Oh, and I was planning to export an existing (single) Redmine project from another instance to the first project I set up. This numbering scheme just made that a somewhat silly and complex task.

#7 Updated by claude g almost 7 years ago

Je suis également d'accord avec ce qui est demandé qui doit être vu comme une amélioration.
Quelqu'un peut-il ajouter le lien avec #6642 plus complet ?
Une évolution intermédiaire relativement plus facile à faire pourrait-être d'ajouter dans les champs customisés la possibilité d'avoir incrémental automatique pour le type 'Entier' en plus d'une valeur par défaut. Cet incrémental évoluerait par projet et non par type de tracker. Il serait également modifiable comme les autres champs customisé au moment de la création ou l'update, c'est uniquement sa valeur par défaut qui serait l'incrémental proposé. Pourriez-vous proposer un patch assez basique pour cela s'il vous plait ?
Plus généralement, des valeurs 'clé' dans le champs 'Valeur par défaut' type &heure pour insérer l'heure courante permettrait d'ajouter encore plus d'intérêt à ces champs customisés à mon avis. Maintenant, je ne vois pas comment cela peut être fait pour indiquer 'la valeur précédente+1' car la valeur précédente à retrouver n'est pas évidente (dans le projet, en fonciton des tracker ou non etc.).

#8 Updated by Etienne Massip almost 7 years ago

claude guerin wrote:

Je suis également d'accord avec ce qui est demandé qui doit être vu comme une amélioration.

Please write in English here.

#9 Updated by Vincent Polite over 6 years ago

Apologies for adding to this thread, but I was curious if any resolution were forthcoming? I am currently adapting redmine for my organization. I personally don't care about issue#s being reflective of the Project. It would be nice if we had an option that also included the project name with the issue hyperlink, however, as that would make things easier. I can also see why people would want unique issue ids on a per project basis, but personally I'd rather have unique numbers across the Redmine installation and not have to worry about a 2 part primary key to track that.

That said, if IDs in the autosequencing are somehow reserved/incremented based on the number of projects you have active, that seems silly. However, I do not experience this behavior, so perhaps this was a bug that was quashed.

NOTE I didn't realize this issue was marked "Closed" - why isn't this shown in the ticket messaging?

#10 Updated by Lubos Racansky about 4 years ago

This is asked for too many times but always closed. Compare to Jira, I miss that feature most.

#11 Updated by Andriy Lesyuk over 3 years ago

It was implemented in the ISSUE-id plugin.

Lubos, it's much like in JIRA, by the way...

Also available in: Atom PDF