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

RESOLVED FIXED in Bugzilla 2.22

Status

()

--
enhancement
RESOLVED FIXED
18 years ago
13 years ago

People

(Reporter: dovw, Assigned: glob)

Tracking

2.10
Bugzilla 2.22
Bug Flags:
approval +

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

18 years ago
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.
Target Milestone: --- → Bugzilla 2.16
Priority: -- → P2

Comment 1

17 years ago
-> New Bugzilla Product
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → 2.10

Updated

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

Gerv
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18

Comment 4

17 years ago
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

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

Comment 6

17 years ago
> 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.
*** Bug 100390 has been marked as a duplicate of this bug. ***

Comment 8

17 years ago
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?
Hmm, now that's an interesting thought...

mpt: what's you're take on the clutter factor?
This bug is really hard to find. Adding some words to summary.
Summary: v2.10 Misleading interface after modifying bug seems to display form of bug just modified → v2.10 Misleading interface after modifying bug seems to display form of bug just modified (next bug is shown after submitting/committing)
*** Bug 133671 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Summary: v2.10 Misleading interface after modifying bug seems to display form of bug just modified (next bug is shown after submitting/committing) → Misleading interface after modifying bug seems to display form of bug just modified (next bug is shown after submitting/committing)

Comment 12

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

Comment 13

17 years ago
I'd like people to consider the user prefs mentioned in bug 29408
*** Bug 157204 has been marked as a duplicate of this bug. ***

Comment 15

17 years ago
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

16 years ago
Created attachment 103223 [details] [diff] [review]
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

16 years ago
Created attachment 103224 [details] [diff] [review]
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).
Attachment #103223 - Attachment is obsolete: true
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.
Attachment #103224 - Flags: review-

Comment 19

16 years ago
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?
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

16 years ago
I vote for saving the default value of the checkbox in the profile.  I don't
like cookies because I use different machines.
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

16 years ago
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?
Hey...  I like that. :-)  Good idea!

Comment 25

16 years ago
Taking this bug.
Assignee: myk → jeff.hedlund
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

16 years ago
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

15 years ago
If this is blocked by a bug that is not targetted for 2.18, it won't make it
either.  Prove me wrong, Jeff.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20

Comment 29

15 years ago
This bug advocates more checkboxes?

Comment 30

14 years ago
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

14 years ago
[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

14 years ago
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)
*** Bug 281906 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Assignee: jeff.hedlund → create-and-change
Severity: normal → enhancement
Priority: P2 → --
QA Contact: mattyt-bugzilla → default-qa
Summary: Misleading interface after modifying bug seems to display form of bug just modified (next bug is shown after submitting/committing) → User preference for whether or not to go to the next bug after processing
Target Milestone: Bugzilla 2.20 → ---
(Assignee)

Comment 34

14 years ago
Created attachment 183373 [details] [diff] [review]
work in progress

work in progress.
Assignee: create-and-change → bugzilla
Attachment #103224 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(Assignee)

Comment 35

14 years ago
Created attachment 183467 [details] [diff] [review]
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".
Attachment #183373 - Attachment is obsolete: true
Attachment #183467 - Flags: review?

Comment 36

14 years ago
(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.
(Assignee)

Comment 37

14 years ago
> 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

14 years ago
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. :)
Attachment #183467 - Flags: review? → review-
(Assignee)

Comment 39

14 years ago
Created attachment 184833 [details] [diff] [review]
patch v3

this patch addresses all the review points.  thanks LpSolit :)
Attachment #183467 - Attachment is obsolete: true
Attachment #184833 - Flags: review?(LpSolit)
(Assignee)

Comment 40

14 years ago
Created attachment 184841 [details] [diff] [review]
patch v4

same a v3, only i actually ran run_tests.
*sheepish grin*
Attachment #184833 - Attachment is obsolete: true
Attachment #184841 - Flags: review?(LpSolit)
(Assignee)

Updated

14 years ago
Attachment #184833 - Flags: review?(LpSolit)

Comment 41

14 years ago
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! :)
Attachment #184841 - Flags: review?(LpSolit) → review+

Updated

14 years ago
Flags: approval?
Target Milestone: --- → Bugzilla 2.22
Flags: approval? → approval+

Comment 42

14 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Keywords: relnote

Comment 43

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

Comment 44

13 years ago
What version of Bugzilla is this patch against?  Anyone know?
(Assignee)

Comment 45

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

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

Comment 46

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

Comment 47

13 years ago
Added to the Bugzilla 2.22 Release Notes in bug 322960.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.