157567 - Reassigning bugs should point by default to the logged in user, not to the current assignee

Status: RESOLVED WONTFIX

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Tobias Burnus]

Usually if you want to reassign you want to reassign to yourself
.
I propose that one replaces the current (a bit shorted excerpt):
 <input name="assigned_to" value="[% bug.assigned_to_email FILTER html %]">
by
 <input name="assigned_to" value="[% user.login FILTER html %]">
in bugzilla/template/en/default/bug/edit.html.tmpl

Alternatively one can natually add an extra radio button or add a
  (currently assigned to <tt>[% bug.assigned_to_email FILTER html %]</tt>)
behind the <input> field.

Comment 1

[Frédéric Buclin]

Taking! This really makes sense. Everytime I reassign a bug, well... it's to me!

There is no interest to reassign by default to someone who already is the assignee.

Comment 2

[Frédéric Buclin]

Attachment: reassign to the logged in user or the reporter

The rule is very simple:

If the user is not logged in or is already the assignee, then reassign to the
reporter, else to the user.

Comment 3

[Frédéric Buclin]

Comment on attachment 164781 [details] [diff] [review]
reassign to the logged in user or the reporter

simple and useful patch.

Comment 4

[Frédéric Buclin]

Comment on attachment 164781 [details] [diff] [review]
reassign to the logged in user or the reporter

Forget it! This patch is incomplete and process_bug.cgi needs some work.

The point is that actually, the way to check if a user is allowed to reassign a
bug is to check if the "assigned_to" field has changed, independently of
whether "Reassign to..." is really selected or not! Moreover, unconfirmed bugs
are "virtually" set to NEW, that is, it's still marked as unconfirmed in the
DB, but CheckCanChangeField thinks that field has changed, so that users
without editbugs privs cannot reassign! I really don't like this indirect way.

This bug strongly depends on bug 193125 which needs to be fixed first.

Comment 5

[Vlad Dascalu]

Comment on attachment 164781 [details] [diff] [review]
reassign to the logged in user or the reporter

+      [% IF !user.login || user.login == bug.assigned_to.email %]
+	 [% reassign_to.email = user.login %]

This is incorrect.

.email shouldn't be assigned to .login or shouldn't be compared to it, since
they are practically different in case someone uses the emailsuffix parameter.

See bug 258712 or bug 255913 for details.

Comment 6

[Frédéric Buclin]

Thanks for the review, vladd! I forgot to consider the emailsuffix parameter as
I never use it. :)

From what I see in bug 264868, bug.assigned_to.email should be replaced by
bug.assigned_to.login.

I will wait the check-in of patches in bug 264868 before updating my patch.

Comment 7

[alanjstr]

Actually, I like to reassign away from me and to nobody@ because I'm not working
on the bug.  However, I do think Me is better than the current assignee.

Comment 8

[Kevin Benton]

I wholeheartedly disagree with changing it from the assignee to me.  I would
request that this be an OPTION rather than a hard change.  There are reasons for
leaving it as-is - if nothing else, to remind the user who the bug is assigned
to currently.  I believe that this will introduce potential process issues,
especially if a user accidentally clicks on the wrong radio and reassigns the
bug to themselves when they meant to reassign to owner and qa contact.

On the other hand, there are times when users want to change status and
reassign.  It also seems to make sense to me to change it to read...

o Reassign bug to  o Me  or  o [_______________]

or...

o Reassign bug to Me
o Reassign bug to [_______________]

In any case, I still think it's appropriate to leave the current assignee in the
box.

Comment 9

[alanjstr]

I disagree with that notion.  If you want to leave the bug unchanged, you leave
the top radio button selected.  If you want to change it, you pick a radio
button.  Clicking the wrong radio button won't correct that problem.  In what
situation would you ever want to reassign it to the person already assigned? 
That's not something you do on purpose, since it is meaningless.  

Comment 10

[Kevin Benton]

(In reply to comment #9)
> I disagree with that notion.  If you want to leave the bug unchanged, you leave
> the top radio button selected.  If you want to change it, you pick a radio
> button.  Clicking the wrong radio button won't correct that problem.  In what
> situation would you ever want to reassign it to the person already assigned? 
> That's not something you do on purpose, since it is meaningless.  

That's why I suggested to make this a parameter and also suggested the "Reassign
to Me" radio.  We disagree on the implementation.  Part of the reason why I
*LIKE* having the current assigned-to person listed there is the benefit of
seeing it while I consider changing it.  It forces me to see it.  On the other
hand, if you change it to show the user, then that functionality is lost.  Since
your goal is to make it easier to reassign a bug to the user, it seems to me
that my suggested method would accomplish both goals simultaneously without any
loss of functionality.  It also seems that making a change to add the addtional
possible selection would be no more difficult than submitting the bug listed above.

Comment 11

[Frédéric Buclin]

Well, then we could consider something like:

 [X] Reassign bug to [_________] (currently assigned to: [e-mail])

Comment 12

[Paul]

(In reply to comment #11)
> Well, then we could consider something like:
>  [X] Reassign bug to [_________] (currently assigned to: [e-mail])

IMO It's overkill but okay.
If I understand the current status is that this bug is to change the 
if ( the bug is assigned to me ) {
[X] Reassign bug to [___default component owner here______]
}
else {
[X] Reassign bug to [___me______]
}

If I go out of my way to move that radio button, you can assume I know why.

Comment 13

[Olav Vitters]

I would really like this fixed before 2.24. Blockers have been fixed.. I also had a patch for this, but noticed this bug when checking for dupes.

Setting target milestone to 2.24. Hopefully you agree, otherwise please reassign to me. Disagree btw that this would be confusing. For me it is confusing to have to do extra steps when reassigning.

Comment 14

[timeless]

i use reassign to current owner when i want to squish the ASSIGNED or REOPENED states and leave a bug at NEW or UNCONFIRMED. but i'm an evil power user.

Comment 15

[Frédéric Buclin]

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

Comment 16

[Stephan Heinersdorff]

I'm only a user and not into the details of how to fix this issue, but I would really appreciate to have a quick and easy way to reassign a bug to myself.
Ideally reassigning AND accepting of the bug should be performed in just ONE step (I don't see any use case, where you would reassign a bug to yourself and then not accept it).
This would save time and reduce the number of emails to the CC-list.

Thanks to whoever is going to implement this.

Comment 17

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 18

[andreas.vinsander]

(In reply to comment #16)
> I'm only a user and not into the details of how to fix this issue, but I would
> really appreciate to have a quick and easy way to reassign a bug to myself.
> Ideally reassigning AND accepting of the bug should be performed in just ONE
> step (I don't see any use case, where you would reassign a bug to yourself and
> then not accept it).
> This would save time and reduce the number of emails to the CC-list.
> 

+1 on that! It is really annoying to first re-assign to an email-address and then change status to assigned.

Choosing "assign" or "accept" should in my opinion by default assign the bug to the current user (if he has sufficient rights). Re-assign could still have the current behaviour if that is implemented.

Comment 19

[Frédéric Buclin]

Radio buttons no longer exist, nor does the "reassign to" field we are talking about in this bug. Comment 16 and comment 18 are another RFE.