'Back to query' when no query has been used

[Emmanuel Blot]

I'm not sure whether its a feature or a bug:

When a ticket is entered in the search box with the quickjump syntax, the ticket page contains the usual "previous ticket", "back to query" and "next ticket" links.

The "back to query" link is quite unexpected, as no query has been used to reach the ticket page, and the default report ({6}) seems to come a bit out of the blue to me.

I would have expected that in this case (no query, direct access to the ticket) the 'Back to query' link not to be shown, and that 'previous ticket' and 'next ticket' links lead to the immediate existing tickets, i.e. for ticket #N, 'previous ticket' jumps to ticket #N_-1 and 'next ticket' jumps to ticket #N₊₁, whatever their status (closed or not)

[Christian Boos]

What you expect is what should usually happen, unless the ticket you're visiting is part of the saved tickets for a custom query or a report (the last one executed).

It's probably what happened here.

[Emmanuel Blot]

Replying to cboos:

It's probably what happened here.

I'm not sure whether this ticket has been retrieved through a custom query in the past, but it's definitely in the past: I've closed and re-open my browser (FF) before submitting this very ticket (#6330, not the test ticket).

Anyway, it should not be dependent of what happened at some point in the past: it the ticket has been reached through a query or a report, the behaviour is ok but it is not for the other use cases ;-)

[Christian Boos]

Do you agree for a wontfix here, or otherwise, what do you suggest?

(I'd hate to put a needinfo here :-) )

[Emmanuel Blot]

Replying to cboos:

Do you agree for a wontfix here, or otherwise, what do you suggest? (I'd hate to put a needinfo here :-) )

I don't think it can be considered as a wontfix ticket: it's definitely a bug, Trac creates fake links unrelated to the user request.
It needs to be fixed some way, in a later release.

I did not have a look at the code about how the link is being created. Is it a cookie ?

[Christopher Lenz]

The list of ticket IDs from the most recently executed query is stored in the user's session. If that list is in the session, and the ticket the user is currently viewing is in that list, then the “Back to Query” link is shown.

I agree that it can be confusing. The underlying problem here is that we don't know whether the user actually “came from a query” (either directly or indirectly). The only option is really make this solid would be to use URL rewriting in all ticket links in a query, and the “Previous/Next Ticket” links, basically adding a query string parameter of some sort. That's kind of ugly though, but we should eventually tackle it in a future major release (note that this behavior has been in place since 0.9).

[Christian Boos]

OK, if we're talking about improving the current behavior, I agree it's not a wontfix. It's definitely not a bug as it behaves as designed, but we can improve the design.

Replying to cmlenz:

… The only option is really make this solid would be to use URL rewriting in all ticket links in a query, and the “Previous/Next Ticket” links, basically adding a query string parameter of some sort. That's kind of ugly though, but we should eventually tackle it in a future major release (note that this behavior has been in place since 0.9).

A solution which would be moderately ugly would be to add a query=n parameter, with n a number in the 0-9 range. That would have the additional advantage of allowing the user to go through multiple result lists at the same time, which is currently not possible with the unique implicitly saved query results.

Implementation details: instead of using the query_time, query_constraints and query_tickets, we would use query0_... and latest_query = 0 or sort through queryn_time to find the latest. When saving and creating the links, we cycle n through 0-9 and when displaying a ticket, we just pick n from the query parameter if present, otherwise we don't show a Back to query link. The queries and reports will save the tickets in a cyclic way in the

[osimons]

Agree this can be confusing, but I don't think adding more alternatives and options to the experience is the way to go.

As a very simple short-term workaround, could we change the words slightly so that the link said 'View Last Query', 'Last Query: Previous Ticket' and so on?

[Emmanuel Blot]

Actually, it's even worse. I just experienced another way of getting more confused with these invalid links:

1. I clicked on a ticket link (from a changeset page), so the browser jumped to the designated ticket (#!884).
   • in this ticket page, two links appeared "Previous Ticket" and "Next Ticket"
2. I clicked on "Next Ticket", which brough the browser to the next ticket , #885
   • again, in this ticket page, two links appeared "Previous Ticket" and "Next Ticket"
3. I clicked on "Next Ticket", which brough the browser to the next ticket , #886
   • here, a different story: on this ticket, three links appeared: "Previous Ticket", "Back to Query" and "Next Ticket".
     Refreshing the browser page did not help: always 3 links, one "out of the blue"
4. I clicked on "Next Ticket", which brought the browser to a random ticket, #478 !

I'm sure there's a reason for this behaviour (stored session that matchs a query leading to #886 ?) however this behaviour is not only highly confusing - a user does not expect a linear, then pseudo-random, traversal of the ticket DB - but appears to the end user as a real bug.

If there is no programatic way to ensure that the prev and next ticket links work in a consistent manner, then I believe the links should be removed rather than leading the user to some random (or actually based on an ancient request) ticket page.

I'm not sure how "It's definitely not a bug as it behaves as designed," ;-)

[Christian Boos]

#8238 was closed as duplicate.

[Christian Boos]

With attachment:clear-saved-query.patch:ticket:9604​, it will be possible to clear the last saved query. This will not completely address the problem here (the surprise factor), but can nevertheless help.