When moving ticket to other milestone, position is wrong

Bug #439948 reported by Knut Eldhuset
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
trac-backlog
Invalid
Undecided
Unassigned

Bug Description

When moving a ticket to another milestone, it's position is the same as it had in the milestone it came from. I think it should be put at the bottom of the milestone it is moved to. You probably want to place it manually anyway, and that is easier if the ticket is appearing in some deterministic location.

I am using version 0.2.1.

Changed in trac-backlog:
status: New → Triaged
Revision history for this message
John Szakmeister (jszakmeister) wrote :

This is actually a feature. The idea behind maintaining a backlog to organize the tickets absolutely in the unscheduled backlog, and then bring them into your sprint. It maintains the ordering that you and your team decided on. It also allows you to move the ticket back out of the sprint, and still retain the ordering your team had decided on.

FWIW, several commercial apps that do this sort of thing behave exactly the same way. For example, the GreenHopper plugin for Jira has this behavior.

Revision history for this message
Knut Eldhuset (knutel) wrote :

Now that you mention it, this behavior makes perfect sense. My problem was caused by the initial rank being equal to the ticket id. I already had milestones called "Backlog" and "SprintX". Both milestones had tickets assigned to them before installing the plugin. When I moved tickets from Backlog to SprintX and back, the ordering was not what I expected, since the tickets already in SprintX were not originally ordered in relation to the tickets in Backlog.

It all makes sense now, but perhaps it should be noted somewhere that you really need to start with an empty sprint milestone?

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Ah, yeah that makes sense. So what I did was add a paragraph to the README describing how the initial ranking is done for an existing Trac instance and the fact that tickets are ranked absolutely... so you may want to spend some time sorting them.

However, now that I think about it, maybe the way I initially assign tickets can change a little. Perhaps I can have all tickets in a milestone be ordered one after another. Have the milestone with the closest deadline get higher ranks, and work down from there. Seems reasonable to implement.

I'm going to go ahead and close this ticket. Thanks for taking the time to fill out a bug report and try TracBacklog! Hope you find it useful!

Changed in trac-backlog:
status: Triaged → Won't Fix
status: Won't Fix → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.