193125 - Reassign bug forces attempt to change to NEW even when not specified

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Stewart Gordon]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126

If I try to reassign one of my own bugs (in this instance a tracker), I get a
bogus error message:

"You tried to change the bug_status field from UNCONFIRMED to NEW, but only the
owner or submitter of the bug, or a sufficiently empowered user, may change that
field."

Firstly, I _am_ the submitter of the bug (though this problem is addressed in
bug 76770), secondly, I didn't try to change the bug status.

Reproducible: Always

Steps to Reproduce:
1. While not logged in, open a bug that I have submitted and is unconfirmed.
2. Select "Reassign bug to", put my own email address in, leave "and confirm
bug" OFF, commit changes.
3. Log in.
4. Go back to the bug page and reload it.
5. Try reassigning it again, commit changes.
Actual Results:  
1. At this time of writing, the bug at the above URL is my own submission,
unconfirmed and assigned to [e-mail].  (Note comment, "You might
want to assign that bug to yourself.")  Options appear include

<> Reassign bug to [[e-mail]]
  [] and confirm bug (change status to NEW)

2. Page asking me to log in appears

3. The above error message appears.

4. Reassign option is still there, but the checkbox for "and confirm bug" has
disappeared.

5. Same bogus error.

Expected Results:  
Allowed me to reassign the bug on the above grounds, and not tried to change the
status at the same time.

Comment 1

[Bradley Baetz (:bbaetz)]

There was another bug on this sometime last week. This got 'fixed' later, either
in 2.17.2 or 2.17.3 (or maybe only in CVS) because the behaviour changes, so
even though th ebg is still there it doesn't matter.

I couldn't find that bug in a quick search, though

Comment 2

[chaduv]

Was this fixed by the fix for bug 164470? Or related at all?

Comment 3

[Bradley Baetz (:bbaetz)]

Not sure. Does it still happen in CVS bugzilla?
(http://landfill.bugzilla.org/bugzilla-tip/)

Comment 4

[chaduv]

I can't create accounts on landfill tip that don't have editbugs and canconfirm
:). On local tip, it's reproducable.

Comment 5

[Frédéric Buclin]

Taking! This problem still exists in 2.19.1+.

We do not want the reporter to be able to reassign its bugs, and the error
message should say the truth!

From IRC:
<myk> the reporter may have some rights that users in general don't have, but i
don't think that should include being able to decide who gets assigned to a bug

Comment 6

[Frédéric Buclin]

If there is a dupe, keep this one open or reassign the other bug to me (if not
already assigned). Thanks!

Comment 7

[Stewart Gordon]

(In reply to comment #5)
> Taking!  This problem still exists in 2.19.1+.
> 
> We do not want the reporter to be able to reassign its bugs, and 
> the error message should say the truth!

And the radio buttons adjusted accordingly.

> From IRC:
> <myk> the reporter may have some rights that users in general don't 
> have, but i don't think that should include being able to decide 
> who gets assigned to a bug

Even if it's assigning a tracker bug to his/herself, as I was once told is a
sensible thing to do?

And didn't bug 76770 use to be about what you're talking about?  The topic of
discussion seems to have drifted a bit.  This bug is about the fact that it
ignores the "and confirm bug (change status to NEW)" checkbox, instead assuming
it to be checked.  Nothing *directly* to do with the theoretical right or not to
reassign bugs.

Comment 8

[Frédéric Buclin]

(In reply to comment #7)
> And the radio buttons adjusted accordingly.

Right! I already thought about this; do not hesitate to remind me this point if
I finally forget to update the UI: ;) But this requires to modify Bug.pm a bit
(a line or two) and I need to check this doesn't break anything else.


> Even if it's assigning a tracker bug to his/herself, as I was once told is a
> sensible thing to do?

The owner of the bug is allowed to reassign bugs, even if he/she is the
reporter. CheckCanChangeField first checks if you are the owner, if not, then if
you are the reporter.

Comment 9

[Frédéric Buclin]

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

Comment 10

[Dave Miller [:justdave]]

I'm going to agree with what Stewart said in comment 7.  The correct fix for
this bug is ONLY to a) make sure the state of that checkbox is honored
correctly, b) if the person doesn't have canconfirm privs, don't confirm it.

(b) should be happening already anyway, it's not clear from this bug whether
that's broken or not.  It's pretty clear that (a) is broken though.

Comment 11

[Frédéric Buclin]

(In reply to comment #10)

Some explanations seem necessary here:

What Bugzilla actually does when someone tries to reassign a bug is to
*virtually* change the status of the bug to NEW, independently of whether the
bug is confirmed or not. This is a way to only allow users with editbugs privs
or the assignee / QA contact to reassign bugs. But what Bugzilla *really* does,
that is what Bugzilla put in the DB depends on the actual status of the bug: if
UNCONFIRMED, then unchanged, else NEW, as expected.

But this solution is bad for several reasons:

1) Bugzilla checks for the status change to determine if a user has the right to
reassign a bug or not. This is bad because reassignment and status change are
two different things. We could imagine that an administrator wants to allow some
users to change the bug status but not to reassign bugs, for example.

2) If the bug is already confirmed, this test fails.

3) As said, Bugzilla does not explicitly check if the user tries to reassign the
bug or not; it only checks the status change. This means that if a user change
the "assigned_to" field without the intention to reassign the bug ("Reassign bug
to..." is not checked), Bugzilla complains that you tried to change the assignee
of the bug. If Bugzilla would check correctly what the user tries to do, it
should ignore this change. This point blocks bug 157567.

4) A user is able to confirm a bug he submitted thanks to the "security hole"
(well, justdave says it's not ;) ) mentioned in bug 266579. So checking what the
status is isn't the safest way to go.

As this bug is strongly correlated with bug 266579, I decided to write a single
patch for both bugs, see my comments 13 and 17 there.

See also bug 271023 about process_bug.cgi cleanup.

Comment 12

[Frédéric Buclin]

*Fixed* by the checkin in bug 266579 (as I said in the previous comment, I
decided to merge the two patches in a single one; as fixing one bug required to
fix the other one too)! :)