Feature #11858

Next issue number after deleting an issue

Added by Wojtek … about 9 years ago. Updated over 7 years ago.

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

0%

Category:Issues
Target version:-
Resolution:Wont fix

Description

In case we delete an issue number 'x' which is currently last one the next created issue is still number x+1. It would be convenient that the next one would be still 'x' to avoid ghost issues (i.e. numbers that doesn't point to any issue

History

#1 Updated by William Roush about 9 years ago

I'd vote no on this one, first it's kind of cumbersome to do due to autonumbering, on top of that it leads to a lot of problems (if I link to issue #100 and it gets deleted, when what would be 101 gets created, my link now links to the wrong issue).

I've seen requests like this for just about every auto-numbering system available, and all of them is really micromanagement. Don't want gaps ever? Don't delete tickets.

#2 Updated by Wojtek … about 9 years ago

Don't want gaps ever? Don't delete tickets.

Simple case - user doubleclicks "create" on the issue page which leads to two tickets of which one can/has to be deleted.

#3 Updated by Etienne Massip about 9 years ago

Wojtek K. wrote:

Don't want gaps ever? Don't delete tickets.

Simple case - user doubleclicks "create" on the issue page which leads to two tickets of which one can/has to be deleted.

This should have been fixed in Redmine, double post should not happen anymore.

#4 Updated by Wojtek … about 9 years ago

Still, case with issues submited by e-mail (i.e. spam filtering problem not working in 100%)

#5 Updated by William Roush about 9 years ago

Wojtek K. wrote:

Don't want gaps ever? Don't delete tickets.

Simple case - user doubleclicks "create" on the issue page which leads to two tickets of which one can/has to be deleted.

Reject it as a duplicate, relate it to the duplicate ticket.

The main limitation is basically how all database systems have done auto-numbers since forever, the overhead of maintaining the empty slots gains you really nothing except database fragmentation and a warm and fuzzy feeling that you don't have "holes" in your auto-numbers.

Wojtek K. wrote:

Still, case with issues submited by e-mail (i.e. spam filtering problem not working in 100%)

Reject as invalid.

#6 Updated by Jean-Philippe Lang about 9 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

Having to reset database sequences is not something I'd like to implement. Sorry but this is a no.

#7 Updated by zhiguo Zhu over 7 years ago

+1

#8 Updated by Toshi MARUYAMA over 7 years ago

  • Category set to Issues

Also available in: Atom PDF