Status
()
People
(Reporter: casey_daniell, Assigned: justdave)
Tracking
Details
(Whiteboard: [fixed-in-trunk])
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: When a no-authority user attempts to reassign an issues that he owns bugzilla seems to want to change the status to NEW, but since the user doesn't have the authority to confirm the issue, it won't let him reassign it. Similarly, i've just noticed that if the user DOES have the authority to edit/confirm issues, an unconfirmed issue's status is changed to NEW upon reassigning it to someone else (even though everconfirmed is still 0). I believe that the status should remain UNCONFIRMED. Reproducible: Always Steps to Reproduce: 1. 2. 3.
(Assignee) | ||
Comment 1•16 years ago
|
||
I'm pretty sure this is a dupe, but I don't remember where the original is, and can't find it in my quick glance. If nobody beats me to it I'll come back and do a more thorough search later when I have time. This may already be fixed, I'm not sure. I remember bbaetz and Gerv had a big argument over how to fix it. :-)
Keywords: qawanted
Whiteboard: dupeme
Comment 2•16 years ago
|
||
I don't know about the first one being a dupe. IS this CVS bugzilla, or an older rlease? If CVS, that could be an interaction with that otehr bug I can't recall teh number of ATM. The cancofirm longic is painful... :)
(Reporter) | ||
Comment 3•16 years ago
|
||
This is the 2.16 release of Bugzilla, downloaded off of the downloads area, this is not a CVS (nightly) build.
Comment 4•16 years ago
|
||
Hmm. Hang on a sec. Someone without canedit isn't meant to be able to reassign a bug (unless they're the reporter/qa/assigneed). If they're not, then the error message is correct.
(Reporter) | ||
Comment 5•16 years ago
|
||
To create this problem you need two users that i'll refer to as dummy and power. Assume dummy has no special authority and power has the permission bits for confirming issues and editing issues set. 1. set up (or find) users with permissions described as above 2. log in as power 3. enter an UNCONFIRMED issue, call it issue 10 4. assign the issue to dummy (as if needing some question answered) 5. log out 6. log in as dummy 7. add a comment to issue 10 (as if answering the question) 8. try to reassign the issue back to power 9. you should see the following error message: You tried to change the bug_status field from UNCONFIRMED to NEW, but only the owner or submitter of the issue, or a sufficiently empowered user, may change that field. Does that help?
(Assignee) | ||
Comment 6•16 years ago
|
||
So it sounds like process_bug is treating it as if the "And confirm the bug" checkbox underneath the "reassign to" is checkmarked, even if it isn't...
(Reporter) | ||
Comment 7•16 years ago
|
||
Just a clairfication. In my comment 5, the dummy user becomes an assignee. Acording to Bradley in comment 4, this should allow the user to then reassign the defect/bug to someone else keeping the bug in the UNCONFIRMED state.
(Assignee) | ||
Comment 8•16 years ago
|
||
a quick glance at the template tells me the "and confirm bug" checkbox is not being shown to the user if they don't have canconfirm... here's the relevant process_bug code from 2.16.2: /^reassign$/ && CheckonComment( "reassign" ) && do { if ($::FORM{'andconfirm'}) { DoConfirm(); } ChangeStatus('NEW'); note that ChangeStatus is supposed to deal with setting it to UNCONFIRMED if the bug hasn't been confirmed and you try to set it to new, like so: } elsif (IsOpenedState($str)) { $::query .= "bug_status = IF(everconfirmed = 1, '$str', '$::unconfirmedstate')"; The only way I can figure out that this wouldn't work correctly is if the user's browser was sending the "andconfirm" field with it blank instead of not sending it, since we only check if it was sent at all and not the contents of it (the HTML spec says it's not supposed to be sent at all if the box isn't checked).
Dave, the problem appears to be with this line in sub ChangeStatus of process_bug.cgi: $::FORM{'bug_status'} = $str; # Used later for call to # CheckCanChangeField to make sure this # is really kosher. ChangeStatus is being called with $str = "NEW", so when CheckCanChangeField is called later (as the comment mentions), I get the message: You tried to change the bug_status field from UNCONFIRMED to NEW, but only the owner or submitter of the issue, or a sufficiently empowered user, may change that field. Which looks like it's coming from the CheckCanChangeField sub.
Comment 10•16 years ago
|
||
Mark, where are you trying to do this? I just tried it on the tip and it worked as expected.
(Assignee) | ||
Comment 11•16 years ago
|
||
Earlier comments indicate he's using 2.16.2
Comment 12•16 years ago
|
||
The ChangeStatus("NEW") stuff is Fun, because there are some IF statemetns futher on, which test everconfirmed. Its really a mess - I tried tracing through it at one stage a while back, and I remmebr how convoluted it is. (side note: I don't think that thats portable with postgres :) I seem to have hosed my 2.16 install at some point; Ill try to test this later this afternoon.
(Assignee) | ||
Comment 13•16 years ago
|
||
I actually made that work on Sybase with a convoluted nested CASE WHEN statement.... $::query .= "bug_status = " . SQLIf("bug_status IN($open_state)", SQLIf("everconfirmed = 1", SqlQuote($str), SqlQuote($::unconfirmedstate) ), "bug_status"); SQLIf() converts to IF($a, $b, $c) in MySQL and to CASE WHEN $a THEN $b ELSE $c END in Sybase. I think Postgres' syntax on CASE WHEN is the same, actually...
Comment 14•16 years ago
|
||
Yeah, postgres follows ansi. ISTR there being a shorter IF/THEN/ELSE thing though, (similar to mysql), but I'm not sure.
Comment 15•16 years ago
|
||
OK, I reproed this under 2.16.2. What happens is that we always set teh bug_status to NEW in the perl, but then in the SQL we use hte IF construct to work arround this. CheckCanChangeField doesn't know, and so it errors out. This affects any bug where everconfirmed has never been set. This doesn't happen in CVS because we now allow the assignee to confirm the bug. Since this is fixed in CVS, its a pain to backport, and I can repro this in 2.14 as well (I didn't try older versions), and noone else has reported this in the past 18 months, I'm tempted to WONTFIX this. Thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
OS: Windows XP → All
Hardware: PC → All
Whiteboard: dupeme → [fixed-in-trunk]
Version: unspecified → 2.16.2
(Assignee) | ||
Comment 16•16 years ago
|
||
It's not dataloss, and it's not a security hole, so it doesn't meet the qualifications for a checkin to a stable branch, anyway. If we know what patch fixed this, let's mark it a dupe of that bug, or resolve it fixed and note that the patch on that bug fixed it.
Comment 17•16 years ago
|
||
I'm not sure which bug fixed it. It wasn't actually fixed; it was just made irrelevent. We do checkin fixes for large breakages for the branch, but since it went so long wthout being noticed.... WONTFIX
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•