The Problem
For example, if I create 3 new tickets, let's say with the IDs
#100, #101, #102 –
then delete #101 and #102 – the
next ticket created gets the ID #101 again,
effectively breaking ticket references in comments, beanstalk
commits, etc. as well as our lighthouse ticket identification in
Hojoki.
We don't know yet since when this has been the case, but are currently looking into it.
Steps to reproduce:
- Create some new tickets (and note the ID)
- Delete some of those newly created tickets
- Create some new tickets again
- Note how the newly created tickets get the IDs of previously deleted ones
#1 Posted by Tiger Team Support staff on 07 Mar, 2013 02:52 PM
Yes, that's always been the case. The number code just does this (ruby)
I suggest you don't delete tickets, just close them with a custom close state. Even if it's "invalid" or "duplicate". Since you're clearly relying on the tickets being there with references from other tickets and external apps, it seems like a really bad idea to be deleting them.
#2 Posted by Jonas Hermsmeie... on 07 Mar, 2013 03:08 PM
Am I reading this right? You are telling me to not use a functionality of your platform because it breaks ticket/commit refs on your platform?
I mean – where's the point in supporting ticket/commit refs at all when it clearly doesn't work persistently, or at all, even within lighthouse?
As I see it, that's a bug – not my fault for using provided default functionality.
#3 Posted by Tiger Team Support staff on 07 Mar, 2013 03:17 PM
Pretty much. We have a lot of features than can conflict with each other; for example you can turn on priorities, set a bunch of things to high priority, turn off priority again, and you've lost the ability to view that information.
So, why are you deleting tickets when they contain important information?
#4 Posted by Tiger Team Support staff on 07 Mar, 2013 03:42 PM
Just to be clear, I'm not disagreeing with the fact that there's a bug; I'm not trying to be facetious, either. It's a refactor I don't think we're going to get done in any reasonable amount of time. There are just two of us working on lighthouse and we have a huge few releases taking all our time.
So the easiest answer is "don't delete tickets if you rely in their information" which includes ticket numbers. Moving to a state workflow that includes invalid-type closed states is what we did a while back and it works well particularly when we reference tickets that were later marked as invalid because we can track why they were "removed" whereas deleting tickets you lose that info.