improve ticket change hints in custom query

[haterw@…]

Steps to reproduce:

1. query tickets owned by user A and B group by owner
2. reassign one ticket found in step 1 to user C
3. query tickets owned by user A and B again, with the same constraint as in step 1

Expect result,

tickets are shown group by user A and B

In fact,

user C with the ticket just assigned to him shown too.

After a quick look at the source code, found it's the cached "query_tickets" session attribute caused the issue. If query constraints keep the same but ticket changed within time delta, query result may be wrong.

[Remy Blank]

In step 3, do you click the "Update" button, or do you just reload the page? The former should remove the modified ticket from the list, whereas the latter will leave it in the list. This is intentional.

[Christian Boos]

I just realized there's no good explanation about this in TracQuery, but I think it really works as it should:

• when a new query is prepared, the results shown all match the filters, as you'd expect
• the result set is also stored in the session, to be able to navigate into this sequence without having to reiterate the query itself
• not only that, but if you now modify tickets and if you "go back" to the query (or simply "refresh" that page), the tickets shown this time will be a combination of the tickets which are now matching the filters and the previous ones, so that you can see what has changed:
  • tickets modified since the initial query are shown in italic
  • new matching tickets are shown in bold (i.e. not necessarily new tickets,
  • and well, tickets no longer matching the filters are also shown in italic…
  This last point could probably be improved.
• It's only when you actually press Update on the query page that you tell Trac to "forget" about your previous working list (and save the current result set as the new working list)

I think this behavior is very useful but we can probably make some improvements. The first would be to document this a bit, the second could be to have some more explicit visual hints, e.g. have a color code on the left border of the modified rows:

• green for new tickets
• red for no longer matching tickets
• orange for modified tickets

And finally, while testing I also found a glitch: a ticket first added then later removed (from the matching set) is nevertheless still shown as added.

[haterw@…]

Thanks for the explanation, it make sense now, trac is a good product that helps us a lot, better to add some doc about this feature.

[Christian Boos]

(removing from {21})