63536 - User preference for whether or not to go to the next bug after processing

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Dov Wachmann]

STEPS: Query Bug, Modify, Commit then recieve confirmation of submission of 
changes. Below confirmation there is the form of a bug report with drop-down 
menus etc.
PROBLEM: Because confirmation message is in large bold font and at top of page 
there is text showing bug number of modified bug (both circled in red in 
attachment)while the bug report interface below it is cluttered it is easy to 
mistake the form as belonging to the bug just modified (I actually did - 
despite the back to bug# link next to confirmation message) and not to realize 
that as spelled out in inconspicuous text (circled in blue in attachment)the 
form is really that of the next bug. Further modifications can then be 
mistakenly made to the wrong bug requiring much correction.

Comment 1

[Jacob Steenhagen]

-> New Bugzilla Product

Comment 2

[Gervase Markham [:gerv]]

This is a fair point, actually. It's really easy to confuse the "Done stuff"
nav. parts with the "Next bug" nav. parts.

Gerv

Comment 3

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 4

[Jeff Hedlund]

I actually did this on my test database, I thought it was showing the results of
my modification, and when I didn't see my changes I changed it again and of
course it went to the next list and then I realized what was going on.

I was looking for another bug that talked about this, but it seems like it would
be better for bug_entry and process_bug to automatically bring up the newly
entered or modified bug, so that things can be changed immediately if desired
(accept assignment, add a comment etc).  It seems an extra painful step to have
to click "Back to Bug #" to go to it. 

Perhaps I am missing something though...

Comment 5

[Andreas Franke (gone)]

Dupe of bug 100390: 'after commit of a new comment, don't follow "next" link' ?

Comment 6

[Jeff Hedlund]

> Dupe of bug 100390: 'after commit of a new comment, don't follow "next" link' ?

Yeah, looks like it!  My only addition is that it would be better if after a new
bug entry it showed the bug as well.

Comment 7

[Dave Miller [:justdave]]

*** Bug 100390 has been marked as a duplicate of this bug. ***

Comment 8

[Jeff Hedlund]

I started to patch this today, and actually have it working where on a new bug,
it redisplays the bug; and on a modified bug it shows the modified bug.

But, I was thinking, what about adding a dropdown to the right of Commit/Reset
that says, "After Committing, show:" with choices like:  "this bug", "next bug",
"the list".   I'd like it to default on "this bug", since that's handiest for me.
(for modifying a bug)

Any thoughts?

Comment 9

[Dave Miller [:justdave]]

Hmm, now that's an interesting thought...

mpt: what's you're take on the clutter factor?

Comment 10

[Andreas Franke (gone)]

This bug is really hard to find. Adding some words to summary.

Comment 11

[Andreas Franke (gone)]

*** Bug 133671 has been marked as a duplicate of this bug. ***

Comment 12

[Jesse Ruderman]

*** Bug 29408 has been marked as a duplicate of this bug. ***

Comment 13

[John Levon]

I'd like people to consider the user prefs mentioned in bug 29408

Comment 14

[Bradley Baetz (:bbaetz)]

*** Bug 157204 has been marked as a duplicate of this bug. ***

Comment 15

[Matthew T (active 1999-2002)]

I suggest just going back to the same bug report, as suggested in comment 4. I
might be biased, but I've never seen the point of `This is the next bug in your
list' -- if it has ever been the bug I wanted to visit next, it's been by sheer
coincidence.

Comment 16

[Jeff Hedlund]

Attachment: Patch v.1

Pretty simple patch, just removed the next_id code and show the bug id that was
just processed (for single bug change).

Made two minor UI changes as well:  Instead of the title just saying "Bug
processed", it now says "Processed: Bug # - Summary".  Similarily I updated
created.html.tmpl to have a title of "Submitted: Bug # - Summary". 

I made those UI changes because I use multiple windows (and multiple tabs in
mozilla), and it's really annoying to lose the bug # and summary when changing
a bug.

Comment 17

[Jeff Hedlund]

Attachment: Patch v.2

Eek- forgot to exit after show_bug().

This patch is implemented without a preference.  Does there really need to be a
preference? (this is currently blocked by bug 98123).

Comment 18

[Dave Miller [:justdave]]

Comment on attachment 103224 [details] [diff] [review]
Patch v.2

You will hear yells and screams from half of the Mozilla community if showing
the next bug after a commit goes away.	There's a reason it's there. :-)

When you're doing things to an entire list of bugs, but you need to look at
them all individually and not do a bulk change, the next bug after commit
REALLY comes in handy.	And it gets done more often than you think.  If this
behavior is changed, it needs to be a preference.

Comment 19

[Jeff Hedlund]

Fair enough, I don't want half the Mozilla community yelling at me :)

I can see how Commit->show_next_bug could come in handy in that situation.

What about some sort of UI change on the edit bug page, maybe a checkbox next to
Commit, something like:

|Commit|  
[x] Then proceed to next bug in list

Make the checkbox a user preference default (that defaults to ON for a new
user).  But if set to OFF, and a user checks it, it will remain set until the
user stops navigating using the Commit button (which could be accomplished with
an argument in show_bug()).

What do you think?

Comment 20

[Dave Miller [:justdave]]

Sounds good to me.  How to save the preference is another question...  should we
just set a cookie or store it in their profile? (bug 98123?)

Comment 21

[Jeff Hedlund]

I vote for saving the default value of the checkbox in the profile.  I don't
like cookies because I use different machines.

Comment 22

[Dave Miller [:justdave]]

I would go for that, too...   the potential problem is if we store it every time
they submit and it's different, but we default it to "next bug" if the person
isn't logged in, then when they log in to commit, it'll save it as "next bug" if
they forget to turn it off...  Then again, it probably ought to default to
"current bug", since it confuses new people.  Existing profiles can get saved in
their personal preferences as "next bug" when the profiles get upgraded, but new
users should default to "current bug".

Comment 23

[Jeff Hedlund]

The way I was describing it to work was this:

Anytime a user goes directly to a bug, via show_bug.cgi or a list or whatever,
the checkbox gets their profile preference.

If a user's preference has it set to OFF by default, and they check it so they
go to the next bug in the list, then Bugzilla should assume they probably will
continue to traverse the list in this fashion-- for this list.  So the
show_bug() routine will have an extra argument to push the current setting of
the checkbox to the next bug.

Therefore:  
A user defaults it to OFF, checks it on for a list, it stays on until they go to
a bug without clicking Commit (at which time it defaults back to the users
preference).

A user defaults it to ON, checks it off for a particular bug, it stays OFF when
that bug is committed, but as soon as they go to another bug it turns back on.

Does that make sense?

Comment 24

[Dave Miller [:justdave]]

Hey...  I like that. :-)  Good idea!

Comment 25

[Jeff Hedlund]

Taking this bug.

Comment 26

[Myk Melez [:myk] [@mykmelez]]

I'm concerned about the added complexity to "show bug".  I think we should have
a user preference but no checkbox to override it, since the checkbox wouldn't
come in handy often enough.

Comment 27

[Mike Cowperthwaite]

I like the basic idea of this bug, but I would prefer to be able to go to a 
stripped down summary page consisting of only the information shown at the top 
of the current Bug Processed page -- no additional bug or list.  Reason being, 
I'm connecting via dialup and would like to be able to make my session react 
more quickly; if I need to get to the list, I can get there faster via my Back 
button.

Comment 28

[Joel Peshkin]

If this is blocked by a bug that is not targetted for 2.18, it won't make it
either.  Prove me wrong, Jeff.

Comment 29

[Christian Reis]

This bug advocates more checkboxes?

Comment 30

[Jeffrey Arcand]

In the user prefs, it would be nice to have more than just a checkbox whether to
show the next bug or not.  It would be nice to have in the preferences "After
Committing, show:" with choices like:  "this bug", "next bug", "the list" and
"nothing" for dialups.

Comment 31

[Kevin Benton]

[14:04] <justdave> probably what we need is on the user preference:
[14:04] <justdave> What do do after submitting changes to a bug:
[14:04] <justdave> (*) Go to next bug
[14:04] <justdave> ( ) return to the same bug
[14:05] <justdave> ( ) ask me each time (but remember my last choice in a cookie)
[14:05] <justdave> if the third one is checked, they get the controls on the
edit bug form

To combine with Jeff's suggestion, add

[ ] query results

Comment 32

[Kevin Benton]

OOPS - missed one...

Here's the "final" update...
(*) Go to next bug
( ) return to the same bug
( ) query results
( ) do nothing (just show me my options)
( ) ask me each time (but remember my last choice in a cookie)

Comment 33

[Marc Schumann [:Wurblzap]]

*** Bug 281906 has been marked as a duplicate of this bug. ***

Comment 34

[:glob ✱]

Attachment: work in progress

work in progress.

Comment 35

[:glob ✱]

Attachment: patch v2

here's a patch that implements the user setting, with the following
differences:

  - no option to view the buglist, it's really hard.  let's leave that for
another bug :)

  - no option to "ask".  i started to implement it, then realised that every
option is already on the page, mainly in the navigation bar

so that leaves "show the next bug in my list", "show the updated bug" and "do
nothing".

Comment 36

[Stephen Lee]

(In reply to comment #35)
>   - no option to "ask".  i started to implement it, then realised that every
> option is already on the page, mainly in the navigation bar

I assumed the "ask" would mean putting a control next to the "Commit" button 
something like:

[ Commit ]  and then  [ Show the updated bug   |v]

Which saves an extra page load (particularly useful on slow connections), and 
can also be the default setting so that the uninitiated are made aware of what 
is about to happen.

Comment 37

[:glob ✱]

> I assumed the "ask" would mean putting a control next to the "Commit" button 
> something like:

myk wasn't keen on that, see comment #26.

i agree with him, the bug page is complex enough and this isn't an action that
you'd want to change often enough to warrent adding it to the page.

Comment 38

[Frédéric Buclin]

Comment on attachment 183467 [details] [diff] [review]
patch v2

>--- process_bug.cgi	12 May 2005 02:07:09 -0000	1.255
>+++ process_bug.cgi	13 May 2005 03:26:00 -0000

>+eval {
>+    require PatchReader;
>+    $vars->{'patchviewerinstalled'} = 1;
>+};

Nit: PatchReader isn't required if you don't want to display any bug after
processing the current one. But this does not hurt here.


>+my $action = Bugzilla->user->setting('post_bug_submit_action');

Two things here:
1) $action is already declared in process_bug.cgi, around line 589. So you
should remove 'my'.
2) Write $action =
Bugzilla->user->settings->{'post_bug_submit_action'}->{'value'}. This way,
there is no need to write a new routine in User.pm.


>+sub setting {
>+    my ($self, $name) = @_;
>+    my %settings = %{$self->settings};
>+    return unless exists $settings{$name};
>+    if (!$settings{$name}{is_enabled}) {
>+        return $settings{$name}{default_value};
>+    } else {
>+        return $settings{$name}{value};
>+    }
>+}

As said above, this routine is useless. Moreover, there is no need to check if
the $name option is enabled or not as User::Settings::new() checks it for you.


>--- template/en/default/global/header.html.tmpl	15 Mar 2005 17:16:24 -0000	1.39
>+++ template/en/default/global/header.html.tmpl	12 May 2005 08:31:54 -0000
>@@ -42,6 +42,8 @@
>+[% IF !global.seenheader %]
>+

>@@ -142,3 +147,5 @@
>+[% global.seenheader = 1 %]

Instead of defining a new variable, use the already declared
$vars->{'header_done'} in process_bug.cgi and add [% IF !header_done %] ... [%
END %] in default/bug/show.html.tmpl around the call to header.html.tmpl:

[% IF !header_done %]

  [% filtered_desc = bug.short_desc FILTER html %]
  [% filtered_timestamp = bug.delta_ts FILTER time %]
  [% PROCESS global/header.html.tmpl
    title = "$terms.Bug $bug.bug_id - $bug.short_desc"
    h1 = "$terms.Bugzilla $terms.Bug $bug.bug_id"
    h2 = filtered_desc
    h3 = "Last modified: $filtered_timestamp"
    bodyclasses = ['bz_bug',
		   "bz_status_$bug.bug_status",
		   "bz_component_$bug.component",
		   "bz_bug_$bug.bug_id"
		  ]
  %]
[% END %]

This way, you don't need to alter header.html.tmpl at all.


>--- template/en/default/global/messages.html.tmpl	12 Mar 2005 21:51:17 -0000	1.26
>+++ template/en/default/global/messages.html.tmpl	13 May 2005 03:18:14 -0000
>@@ -233,7 +233,7 @@
>   [% ELSIF message_tag == "shutdown" %]
>     [% title = "$terms.Bugzilla is Down" %]
>     [% Param("shutdownhtml") %]
>-    
>+
>   [% ELSE %]
>     [%# Give sensible error if error functions are used incorrectly.
>       #%]        

If you don't change anything except some whitespaces, don't include this file
in the patch please.


I have installed your patch and tested all three options. It rocks! I already
love your patch. :)

Comment 39

[:glob ✱]

Attachment: patch v3

this patch addresses all the review points.  thanks LpSolit :)

Comment 40

[:glob ✱]

Attachment: patch v4

same a v3, only i actually ran run_tests.
*sheepish grin*

Comment 41

[Frédéric Buclin]

Comment on attachment 184841 [details] [diff] [review]
patch v4

>+add_setting ("post_bug_submit_action", {"next_bug" => 1,
>+                                        "same_bug" => 2,
>+                                        "nothing" => 3,
>+                                       },
>+             "next_bug" );

Nit: would "process_bug_submit_action" be a better name?

I have tested your patch as much as possible, with users having differents
privs, with products belonging to groups or not, with all three options ("show
the updated bug" is definitely my prefered one ;)), with midair collisions,
product move, unallowed modifications...  and I haven't seen any problem; even
runtests.pl is happy. So... I think this means you get my r+ . Nice patch! :)

Comment 42

[Frédéric Buclin]

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.413; previous revision: 1.412
done
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.264; previous revision: 1.263
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v 
<--  filterexceptions.pl
new revision: 1.44; previous revision: 1.43
done
Checking in template/en/default/bug/show.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.html.tmpl,v  <--
 show.html.tmpl
new revision: 1.11; previous revision: 1.10
done
Removing template/en/default/bug/process/next.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/next.html.tmpl,v
 <--  next.html.tmpl
new revision: delete; previous revision: 1.5
done
Checking in template/en/default/global/code-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/code-error.html.tmpl,v
 <--  code-error.html.tmpl
new revision: 1.53; previous revision: 1.52
done
Checking in template/en/default/global/setting-descs.none.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/setting-descs.none.tmpl,v
 <--  setting-descs.none.tmpl
new revision: 1.4; previous revision: 1.3
done

Comment 43

[Max Kanat-Alexander]

*** Bug 300750 has been marked as a duplicate of this bug. ***

Comment 44

[Gordon Schumacher]

What version of Bugzilla is this patch against?  Anyone know?

Comment 45

[:glob ✱]

> What version of Bugzilla is this patch against?  Anyone know?

it was made against the cvs tip as of 30th may.

Comment 46

[Frédéric Buclin]

*** Bug 319573 has been marked as a duplicate of this bug. ***

Comment 47

[Max Kanat-Alexander]

Added to the Bugzilla 2.22 Release Notes in bug 322960.