Milestone order in query reports

[ols@…]

In Trac version 0.11b1 the milestones were ordered according to their due date in the custom query. In Trac version 0.11b2 the milestones are ordered alfabetically in the custom queries. I liked the 0.11b1 behaviour and hope that the 0.11b2 has a bug that will fixed soon.

[anonymous]

I've found it happened from r6471. Here is instant patch.

ticket/query.py

@@ -530 +530 @@
                 groups.setdefault(group_key, []).append(ticket)
                 if not groupsequence or group_key not in groupsequence:
                     groupsequence.append(group_key)
-        groupsequence = sorted(groupsequence, reverse=self.groupdesc)
+        #groupsequence = sorted(groupsequence, reverse=self.groupdesc)
         groupsequence = [(value, groups[value]) for value in groupsequence]

But I think this is not right way.

[Christian Boos]

No, this is not the right way, quoting from r6471:

any new group introduced by the change would not be sorted correctly.

The correct fix looks more involved, post-poning.

[osimons]

Patch that reworks query caching by adding in sql instead of 'manually' updating afterwards

[osimons]

I think this patch works correct, and handles a number of other issues better - like the already closed issue of graceful removal of deleted tickets in #6088.

Comments?

[Christian Boos]

I've tested it - seems to work great.

As discussed on IRC, this approach fixes a couple of other issues, like the quadratic behavior of L726​ and the slowness of individual ticket retrieval of done at line 730. Also, I was not convinced of the correctness of the sorting done at line 735 (using the index in orig_list to insert into tickets list - tickets list might now well be completely different?). All this code is now gone ;-)

[osimons]

Superb. Committed in [6792].

[trac@…]

I can confirm that the latests trunk fixs this problem.