Closed Bug 35195 Opened 24 years ago Closed 17 years ago

request for "and accept bug" checkbox under reassign radio button

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Platform:
Other
Other
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 3.2

People

(Reporter: dbaron, Assigned: LpSolit)

References

(Blocks 1 open bug)

Details

(Whiteboard: [blocker will fix])

Attachments

(1 file, 1 obsolete file)

v2: Updated patch to match new directory structure
1.98 KB, patch
jouni
: review-
Details | Diff | Splinter Review 
In show_bug.cgi, it would be nice if there were an "and accept bug (change
status to ASSIGNED)" checkbox under the "Reassign bug to" radio button.  This
would allow someone to steal and accept a bug in one move, and would cut down on
email notifications.
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
I very much second this.  I did some work on doing this in my own setup a few
weeks ago.  I might resurrect that and fix it up (it never worked right).
The attached patch does this.  It has been tested on my tree.  Feedback welcome.
ithink there's a dupe somewhere of this. accepting and considering for 
evaluation in 2.12
Assignee: tara → cyeh
Whiteboard: 2.12
I don't get this bug at all, If you want to steal the bug and reassign it to 
yourself, you can just hit the accept button and if you want to assign it to 
someone else, you shouldn't be able to force them to accept it.
Nice idea, unfortunately the 'accept bug' radio button accepts it on behalf of
whoever it is assigned to. IOW, it will never change the Assigned To field.
See also bug 37613.

Removing 2.12 flag.  Not excited about this feature, especially not for 2.12.
Whiteboard: 2.12
Well, do we instead want to make the "Accept bug" change the assignment of the
bug?  People often expect it to, but instead it accepts the bug for the
current owner.
My thoughts are make Accept bug take the bug and set it to ASSIGNED.  IMHO I
should never be allowed to Accept a bug on behalf of someone else.
Whiteboard: 2.16
I *STRONGLY* disagree with the idea that the behavior of ACCEPT should be
changed, without somehow allowing for the current behavior to remain.  It is
fine for people to say "I don't like this behavior", but my group's practice
*DEPENDS* on that behavior.  

We should design an alternative that allows this functionality to be configured,
instead of changing what the options mean by default.
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
Keywords: patch, review
Whiteboard: 2.16
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave
->New product Bugzilla
Assignee: justdave → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
I don't think we should do this. The bug status change section can acquire an
arbitrary level of complexity if we allow for all the possible combinations of
doing two things at once. We have the most common - let's leave it at that.

Gerv
We have two problems.  First, the one mentioned in this bug report: one of the
more common tasks in Bugzilla, reassigning a bug and accepting it, requires two
steps.  This is unnecessarily complicated, and it does matter.  On b.m.o. the
meaning of "ASSIGNED" has become diluted, with many users working fixing "NEW"
bugs and then resolving them "FIXED" without ever having accepted them.

Lack of an "and accept bug" checkbox did not cause this problem, but it does
exacerbate it.  I'm not sure that a checkbox is the solution--I'd like to hear
other ideas for UI for this function--but I'm sure this feature is sufficiently
useful to warrant implementation.

The second problem is the incongruence between the ASSIGNED status and the
assignee field.  "Assigning" or "reassigning" a bug does not change the status
to "ASSIGNED", and bugs are always assigned to someone no matter what their
status.  This incongruence should be corrected, with the most likely solution
being to change the "ASSIGNED" status to "ACCEPTED", since we already use the
phrase "accept bug" to refer to the process of setting the status to "ASSIGNED".
 I have filed bug 104049 on this issue.

I think the way to do this is to move towards checkboxes rather than radio
buttons, where appropriate, so we don't have to enumerate all the combinations.

Some of this is over at bug #92552.
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
*** Bug 135525 has been marked as a duplicate of this bug. ***
I'd go for the checkbox, since it's probably the solution with least impact
anyway. We can rethink this when custom resolutions land.

Removing review keyword anyway, since the patch is 2+ years old and cannot
really be reviewed.
Keywords: review
I took the patch and updated it.
I've got to agree with the "you should not be able to accept a bug for someone
else" faction.

"Round these parts" (deployment of 2.14.4) we've been operating with "Accept
Bug" meaning that the bug involved now becomes your bug if it wasnt in the first
place. This keeps bugs "New" until the owner accepts them or someone else wants
to own them. Keeping them "New" is a good thing, since it makes sorting query
lists easier.

I dont like the idea of "Accept and assign to me", since that implies that you
can accept for someone else (and they may not accept the work! :-)
darn it... that last comment of mine really belonged in bug #37613 :-/
Attachment #8029 - Attachment is obsolete: true
Attachment #91372 - Flags: review?
*** Bug 37613 has been marked as a duplicate of this bug. ***
Comment on attachment 91372 [details] [diff] [review]
v2: Updated patch to match new directory structure

Bitrotten.
Attachment #91372 - Flags: review? → review-
*** Bug 227806 has been marked as a duplicate of this bug. ***
*** Bug 232213 has been marked as a duplicate of this bug. ***
Blocks: 234530
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
(In reply to comments #11 and #12)
> My thoughts are make Accept bug take the bug and set it to ASSIGNED.  IMHO I
> should never be allowed to Accept a bug on behalf of someone else.

I think an acceptable solution would be to make the meaning of the ACCEPT option
be that Bugzilla should *assume* that the user wants the accept this bug for
him-/herself (i.e. REASSIGN to /me and ACCEPT) but should *double-check* with
the user.

E.g. when ACCEPTing a bug that belongs to someone else Bugzilla should display a
"What do you want to do?" question on the next page (similarly to the "confirm
match" dialogue) asking for either

(*) REASSIGN bug to /me/ and ACCEPT bug   or
( ) ACCEPT bug on behalf of /owner/

I believe this would consider comment #12 sufficiently and would do away with
the necessity to pose two actions to reassigning and accepting a bug.

I think this problem *is* imperative to fix, I regularly notice that the ACCEPT
feature is misinterpreted and users accidentally accept bugs on behalf of
someone else (though they really wanted to reassign and accept the bug for
themselves). I myself get sometimes trapped by this misleading feature.
Comment #12 applies to my group also - we often set a bug to ASSIGNED
for someone who is already working on it, e.g. in a group status
meeting, if they forgot, etc.  The proposal in comment #30 is ok, but
it makes the UI more complex (and will it take longer to get done?)

I propose instead a slight change to the original proposal to reduce
the confusion about the word "accept", and simplify the UI (addressing
comment #16):

1. Remove the words "and accept bug" from the checkbox:

   ( ) Reassign bug to [______]
       [_] and change status to ASSIGNED

2. Remove the "Accept bug" radio button (you can do this with the new
   checkbox by leaving the assignee unchanged).  Could also move the
   "Reassign bug" radio button(s) up in its place to match the workflow.
(In reply to comment #31)

I do *NOT* think this would be a good idea: You would be able to reassign a bug
to someone else *AND* accept it on behalf of that person!!

What if that person does not want to accept that bug? Or never gets notified
about a new bug in his/her bug list, because he/she only receives wine mails and
has disabled all other notifications? (I see such a setting regularly with my
colleagues.)

What you mean makes sense only if you reassign the bug to yourself. The meaning
of "ACCEPT this bug" as implemented in the user interface now is intuitive, the
behavior of Bugzilla should be adapted as I propose (comment #30) to reflect the
conceptual model of the average user appropriately, I believe.
Peter, that should still be possible (as is currently) due to the fact that some
business managers, and project leaders should/need to have the ability to take a
bug, assign it to an employee, and set priority/ASSIGNED status.  It all depends
on the companies policy/use.

I know timeless once made claim to this use before, and I gladly accept it as a
reasonable use of bugzilla. (I am not a project lead, nor active developer, only
a user though)
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
Some have complained that fixing this problem would mean that you could force someone else to accept a bug.  Of course, you can already do that.  This change just makes it easier.

In some environments, forcing someone else to accept a bug would be inappropriate.  There are other environments, though, where it is perfectly acceptable and even routine.  As a general-purpose tool, Bugzilla needs to be able to cope with each type of environment.

In particular, in a company, a manager needs the ability to assign a bug report to an employee and to accept it on behalf of the department.  Every bug goes through this same approval processes.  In such an environment, it is a big time-saver to change the current two-step process into a single step.
Richard,

I believe your considerations are not the *real* problem. You say, it would be an enhancement to allow for a single-step process that assigns a task to someone AND accept it on behalf of that person. (Correct me if I'm wrong!)

The actual problem, however, is that users of Bugzilla most probably *expect* that "Accept bug" actually means "I want to work on this bug!".

An appropriate solution to this potentially misleading interpretation: Double-check with the user. I tried to sketch such a solution in comment #30.

The solution proposed by Veda in comment #31 is very much close to your considerations, I guess. Additionally, you would have to implement a way to submit a new bug and set its status to ASSIGNED right away. - But I do NOT think this is a goog idea! You would lead the whole workflow ad absurdum.
QA Contact: mattyt-bugzilla → default-qa
Keywords: dogfood
Keywords: dogfood
Whiteboard: [wanted-bmo]
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
(In reply to comment #36)

> The actual problem, however, is that users of Bugzilla most probably *expect*
> that "Accept bug" actually means "I want to work on this bug!".

I think that depends on the culture of users and administration.  In our case, it means "I'm working on it" whether or not the user really wants to.  It's a method of saying, I've read the bug and agree that I'm the correct person to handle the next step, and that the bug is valid.  In some cases, it's used similarly to an ACK and seen by managers as a performance metric.  Managers want to know how long it takes team members to see and pick up new issues.

In my situation, I don't like the idea that a person can accept a bug on behalf of another, especially if it's possible that the individual is on vacation, out sick, or otherwise unavailable.  OTOH, I do like the idea of being able to accept an issue on behalf of a group.  How do we get to the point where that's possible?  I don't know, but I think it'll involve allowing assignment to groups rather than mailing list users (see Bug 98310).

> considerations, I guess. Additionally, you would have to implement a way to
> submit a new bug and set its status to ASSIGNED right away. - But I do NOT
> think this is a goog idea! You would lead the whole workflow ad absurdum.

I agree, however, when the reporter is taking the bug him/herself, doesn't it make sense to allow it?

I believe any attentive reader of this bug can see that this issue is not only about "My group's practice is different than your's!" but also about misinterpretation of the "ACCEPT" (ASSIGN?!) feature. (If you don't believe so, please go into bug 37613 and read, then come back here again.)

This issue is important, because the current implementation leaves room for deliberate interpretation (which later on automatically leads to, allow me to say, "weired but established" practices).

As suggested in bug 37613 and in my comment 30 of this bug, respectively, we need _configurable behavior_ in order to make everyone happy _and_ not to have a sloppy compromize.

We need all of:

- both buttons

 (*) ACCEPT bug (to work on myself)
 ( ) ACCEPT bug on behalf of /owner/

- as well as a (rather complex) bugzilla configuration switch, such as

 "ACCEPT BUG behavior":

 (*) show ACCEPT only, meaning "set status from NEW to ASSIGNED"
     (even on behalf of someone else)
 ( ) show ACCEPT only, meaning "assign to current user and set status
     from NEW to ASSIGNED"
 ( ) show ACCEPT only and double-check when user to accept the bug
     is not the bug owner (i.e. ask after submit on next page)
 ( ) show 2 options, "ACCEPT bug (to work on myself)"
     and "ACCEPT bug on behalf of $bug_owner"

- Additionally, when option 1 is chosen in the configuration (i.e. the functionality as currently implemented) and the bug is displayed to someone who is _not_ the bug owner,

  (*) ACCEPT bug

should read

  (*) ACCEPT bug on behalf of /bug_owner/


These changes would keep complexity mostly away from the actual, daily user of a bugzilla system. (It is just the administrator that then needs a little bit more time to understand and figure out how he/she best sets the configuration.)

I really like all the suggestions of the comment #39!
Peter, in comment 39, you list a number of possible options, each of which is potentially good.  I think that in order to implement anything like it, one concern is to tie the options to parameters.

I guess my biggest concern here is we're getting stuck in analysis paralysis.  This bug has been open for more than six years.  Some improvement is better than none.  I think we could quickly/easily implement:

( ) Accept bug as mine (sets status to ASSIGNED)

or

( ) Take this bug and accept it (sets status to ASSIGNED)

I see no reason why we can't make one of these "baby steps" toward closure of this issue to make a large number of individuals happy quickly.  Then, after that's implemented, we could decide on what to do next.

Some sites don't want others to be able to accept on behalf of another.  Some sites do.  Some sites would rather see this as a parameter.  Some would not...  I think everyone can agree that making the two-step process of taking ownership and accepting it (changing status to ASSIGNED) could be made a single click on the web while performing the required actions in the bugs_activity log.  We need to make sure that if we do this, we can not forget the implied step of setting the status to NEW for the assignee.  I don't see a problem with adding both bugs_activity entries back-to-back for those that depend on the transition.

More to come later, I'm sure. :)

I've been following this bug for years, and heartily agree with Peter (#39)
and Kevin (#41).  The simplest change IMHO would be to allow the accepter
to assign the bug to him/herself at the same time. (I think this should be
the default behavior, but I understand that not everyone agrees with this :-)

This could be accomplished with either of:

1) A new "Accept bug as mine" action (Kevin's suggestion)
2) A check box under "Accept Bug" labeled "and reassign to me"

Implementing this would satisfy a lot of people, and would not open up the
can of worms involved in the alternative function, described in this bug's
title, of user A assigning the bug to user B and also accepting it for them.

I think these two approaches ("Accept as mine" vs "Assign and accept") are
fundamentally different, and satisfy different constituencies. Do we need a
separate bug to track the "kinder, gentler" alternative ("Accept as mine")?
Is a separate bug for just that option more likely to lead to action?
In order to satisfy both camps (who believe that one should vs. should not be allowed to accept bugs for others) in the simplest way, all in one shot, I propose (a modified version of Peter's proposal in comment #39):

Both buttons to replace the current Accept button:
 (*) ACCEPT bug (to work on myself)
 ( ) ACCEPT bug on behalf of [____________] <- defaults to owner but can edit

Plus a simple boolean parameter to control whether the second button is shown:
 acceptforothers: Allow users to accept bugs on behalf of others.
                  ( ) On  ( ) Off
Assignee: myk → create-and-change
Reed asked me in #mozwebtools for my thoughts on this bug...

The minimal fix is to do something like this:

O Leave as is
O Reassign bug to me
O Reassign bug to [              ]
O Reassign bug to default assignee/QA contact/CC
  [] Accept bug (change status to ASSIGNED)
O Resolve bug, changing resolution to [ FIXED    V]
O Mark the bug as duplicate of bug #[       ]

(where "Accept bug" is enabled when any of the four preceding options are selected).

But ultimately we should decouple assignee and status changes so that we can do something like this instead:

Assignee

O Don't change
O Reassign to me
O Reassign to [              ]
O Reassign to default assignee/QA contact/CC

Status

O Don't change
O Accept (change status to ASSIGNED)
O Resolve [ FIXED    V]
O Resolve duplicate of bug #[       ]

Or, even better, integrate the UI for making changes with the UI for displaying the current value, f.e. by using drop-down menus (shown here always in their opened states):

Assignee: [ John Doe  V]
          | Me         |
          | [       ]  |
          --------------

Status: [ NEW                 V]
        | ASSIGNED             |
        | RESOLVED FIXED       |
        | RESOLVED INVALID     |
        | RESOLVED WONTFIX     |
        | RESOLVED WORKSFORME  |
        ------------------------

Unfortunately, we probably can't embed a text field in a menu item, so the assignee field would have to look like this:

Assignee: [ John Doe        V] [             ]
          | Me               |
          | Someone Else...  |
          --------------------

(where the text field to the right of the drop-down menu is disabled until the user selects "Someone Else..." from the Assignee menu).

And perhaps we'd want to separate status from resolution via two drop-down menus:

Status: [ NEW      V] [ FIXED      V]
        | ASSIGNED  | | INVALID     |
        | RESOLVED  | | WONTFIX     |
        ------------- | WORKSFORME  |
                      ---------------

(where the Resolution drop-down is disabled until the user selects "RESOLVED" from the Status menu).

As an aside, "ASSIGNED" should also be renamed, since bugs are always "assigned" (i.e. they have an assignee), and "ASSIGNED" is being used to mean something else (like "accepted" or "actively being worked on").  The fact that we have to explain that the "accept bug" option means "change status to ASSIGNED" is a clear indication that we should be renaming this field so that its meaning is evident.

(In reply to comment #44)
I would simplify the initial suggestion to something like the following. Maybe
some permission should control whether someone may "accept bugs" (change from "new") for persons not himself/herself. Depending on that, the line with "Accept bug" should move at the end of "to me".
 O  Reassign bug
    [ ] Accept bug (change status to ASSIGNED)
     O  Leave as is
     O  to me
     O  to default assignee/QA contact/CC
     O  to [              ]
 O  Resolve bug
     O  as [ FIXED    V]
     O  as duplicate of bug #[       ]

(I hope the nested radio buttons make my intention more clear)
Reassignment and bug status changes are now decoupled, see bug 92552. You are now free to mark a bug as ASSIGNED and reassign it at the same time.
Assignee: create-and-change → LpSolit
Depends on: 92552
Whiteboard: [wanted-bmo] → [blocker will fix]
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: