578335 - The "Show next bug in my list" user pref either doesn't display the next bug or display one from the wrong buglist

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Frédéric Buclin]

In one QA installation, I have a buglist with two bugs in it. Editing the first bug of this list with the user pref sets to "Show next bug in my list" does nothing. No bug is displayed at all. On another installation, it jumps to a bug being on another random buglist, leaving the current buglist I was using. (thanks to test_user_preferences.t for catching that)

I suspect this is a regression due to bug 24896.

Comment 1

[Max Kanat-Alexander]

  It is most likely not a regression, but more likely either an artifact of how you are doing the tests or the nature of your bug lists.

  If you came to those bug lists from a normal query.cgi submit, as a POST, and were properly redirected to buglist.cgi with a list_id item in the URL, and then you clicked on a bug link from there with a proper Referrer header, this should not be happening. Any deviation from the above and the behavior of the list-management code is unpredictable, but still works to some degree.

Comment 2

[Max Kanat-Alexander]

  Also, the list management code does not work predictably with Saved Searches, if you are using those.

Comment 3

[Frédéric Buclin]

(In reply to comment #1)
>   It is most likely not a regression, but more likely either an artifact of how
> you are doing the tests or the nature of your bug lists.

No, it's definitely a regression. I can reproduce manually. When you edit a bug, you don't click on any "Next" link; this is handled by process_bug.cgi, which is supposed to display the next bug of your *current* buglist.

Comment 4

[Max Kanat-Alexander]

  There's no concept of a current buglist anymore. But if there are multiple matches when we're ambiguous about a bug, we probably should pick the most current list instead of the oldest one. That might be the problem you're running into?

Comment 5

[Frédéric Buclin]

(In reply to comment #4)
>   There's no concept of a current buglist anymore. But if there are multiple
> matches when we're ambiguous about a bug, we probably should pick the most
> current list instead of the oldest one. That might be the problem you're
> running into?

Probably, because I did a query which returned only 3 bugs, I edited the second one (so the header says "2 of 3"), and then it displayed a bug from a query I did a few days ago (and the header suddenly says "44 of 271"). We could store the list ID in a hidden field in the template so that process_bug.cgi knows which list to look at.

Comment 6

[Max Kanat-Alexander]

  Oh, yeah, that might be necessary, the hidden field thing.

Comment 7

[Frédéric Buclin]

Attachment: patch, v1

Looking at more recent buglists first helps a lot, as statistically, you are more likely viewing such a buglist. But this is still not perfect if you run the same query pretty often (such as your favorite saved searches), as its ID remains small and so is rarely caught.

Storing list_id in bug/edit.html.tmpl doesn't help as it comes from $user.recent_search_for() which already tries to guess this list ID based on the current bug. The best solution would be to add a new column profile_search.last_used and update it everytime you access a buglist, so that more recently *used* buglists have higher priority, rather than more recently *created* buglists.

Comment 8

[Max Kanat-Alexander]

Comment on attachment 457707 [details] [diff] [review]
patch, v1

Looks great to me. :-) Thank you. :-)

Comment 9

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified process_bug.cgi
modified Bugzilla/Search/Recent.pm
Committed revision 7379.

Committing to: bzr+ssh://[e-mail]/bugzilla/4.0/
modified process_bug.cgi
modified Bugzilla/Search/Recent.pm
Committed revision 7331.