Closed
Bug 237838
Opened 22 years ago
Closed 21 years ago
resolution wrong in CheckCanChangeField
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Bugzilla
Creating/Changing Bugs
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: karzes, Assigned: gerv)
Details
Attachments
(1 file)
|
777 bytes,
patch
|
gerv
:
review+
justdave
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
I modified CheckCanChangeField to restrict certain "resolution" values, and I
found that the newvalue was sometimes wrong, depending on where it came from (an
example is when someone tries to mark a bug as a "duplicate"). This is because
it's picking the new value out of a form field that's only defined in some of
the cases. The same situation applies to the "bug_status" field, but that cases
works correctly because of a hack at the bottom of ChangeStatus in which the new
value is forced into the form. I made a similar change to ChangeResolution
which seems to have fixed the problem:
sub ChangeResolution {
my ($str) = (@_);
if ($str ne $::dontchange) {
DoComma();
$::query .= "resolution = " . SqlQuote($str);
$::FORM{'resolution'} = $str; # Used later by CheckCanChangeField
}
}
Reproducible: Always
Steps to Reproduce:
1. Customize CheckCanChangeField to check the new value of the "resolution" field.
2. Use one of the specialized knob settings to change the resolution of a bug
(e.g., mark the bug as a duplicate)
Actual Results:
CheckCanChangeField sees the wrong value for the "resolution" field.
Expected Results:
CheckCanChangeField should have seen the correct value for the "resolution" field.
Comment 1•22 years ago
|
||
Hmm, this makes sense to me.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Bugzilla 2.18
| Assignee | ||
Comment 2•22 years ago
|
||
Yep, seems sensible at first look.
Gerv
| Assignee | ||
Comment 3•22 years ago
|
||
This should do the trick.
Gerv
Assignee: myk → gerv
Status: NEW → ASSIGNED
| Assignee | ||
Comment 4•22 years ago
|
||
Comment on attachment 145613 [details] [diff] [review]
Patch v.1
Tom: could you check this is right?
Gerv
Attachment #145613 -
Flags: review?(karzes)
| Reporter | ||
Comment 5•22 years ago
|
||
Looks good to me :)
| Assignee | ||
Updated•22 years ago
|
Attachment #145613 -
Flags: review?(karzes)
Attachment #145613 -
Flags: review?(justdave)
Attachment #145613 -
Flags: review+
Comment 6•21 years ago
|
||
Comment on attachment 145613 [details] [diff] [review]
Patch v.1
r=justdave
This is going to get redone when they get around to sanitizing process_bug.cgi
for %::FORM usage, but it should be easy enough for them to catch then. :)
Attachment #145613 -
Flags: review?(justdave)
Updated•21 years ago
|
Flags: approval+
Comment 7•21 years ago
|
||
Gerv: this appears to be your patch. Care to check it in?
| Assignee | ||
Comment 8•21 years ago
|
||
Sure. :-)
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v <-- process_bug.cgi
new revision: 1.204; previous revision: 1.203
done
Gerv
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•13 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
•