'Back to query' when no query has been used

[eblot]

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)

[cboos]

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.

[eblot]

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 ;-)

[cboos]

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

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

[eblot]

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 ?

[cmlenz]

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).

[cboos]

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?