Closed
Bug 412943
Opened 18 years ago
Closed 17 years ago
When email_in.pl calls process_bug.cgi in Bugzilla 3.0, no qa_contact field causes update failure
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.0
People
(Reporter: alex, Assigned: LpSolit)
Details
(Whiteboard: [3.0.x branch only][3.2 not affected])
Attachments
(1 file, 1 obsolete file)
792 bytes,
patch
|
mkanat
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: 3.0.3
With Param('useqacontact') set, when adding only a comment to an existing bug with email_in.pl, process_bug.cgi fails to update when sender is not in caneditbugs group with the error:
You tried to change the
QA Contact field
from <Component QA Contact>
, but only
the assignee
of the bug, or
a sufficiently empowered user may change that field.
<Component QA Contact> is obvioulsy the QA contact for the component.
Reproducible: Always
Steps to Reproduce:
1. Run email_in.pl either directly or through email alias pipe
2. Input or send email with From: field set to a basic user which created the bug and Subject: field set to [Bug XXX] appropriately, with message content a simple comment
3.
Actual Results:
View output or receive error that says:
You tried to change the
QA Contact field
from <Component QA Contact>
, but only
the assignee
of the bug, or
a sufficiently empowered user may change that field.
Expected Results:
Updating Bug XXX
The bug is actually in process_bug.cgi.
$formhash{'qa_contact'} is set to $qa_contact which may never be defined (e.g. by email_bug.pl), and the later test "exists $formhash{'qa_contact'}" will be true as the value will be undef.
The solution is to only set $formhash{'qa_contact'} when Param('useqacontact') is set AND qa_contact is defined. See attached patch.
Reporter | ||
Comment 1•18 years ago
|
||
![]() |
Assignee | |
Comment 2•18 years ago
|
||
Confirming. This bug also occurs if you hack the URL and omit the QA field.
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 3.0
Version: unspecified → 3.0.3
![]() |
Assignee | |
Updated•18 years ago
|
Assignee: create-and-change → alex
Status: UNCONFIRMED → NEW
Ever confirmed: true
![]() |
Assignee | |
Comment 3•18 years ago
|
||
Comment on attachment 297761 [details] [diff] [review]
Fix to only define $formhash{'qa_contact'} when $qacontact is also deinfed
>- $formhash{'qa_contact'} = $qacontact if Bugzilla->params->{'useqacontact'};
>+ $formhash{'qa_contact'} = $qacontact if (Bugzilla->params->{'useqacontact'} && defined($qacontact));
This fixes the problem with email_in.pl, but introduces a new regression: if a product has no QA contact by default but a QA contact is set on a bug, then your fix lets unprivileged users remove it by hacking the POST data (delete the QA field and set knob = 'reassignbycomponent'). I think I know how to fix the problem. Alex, do you mind if I take the bug and fix it myself, or do you want to give another shot?
Attachment #297761 -
Flags: review-
![]() |
Assignee | |
Updated•18 years ago
|
Flags: blocking3.0.4?
![]() |
Assignee | |
Comment 4•18 years ago
|
||
Thinking about it a bit more, I wonder if I couldn't already hack the data to reproduce my testcase. Investigating...
Reporter | ||
Comment 5•18 years ago
|
||
You are most welcome to take the bug and fix it yourself :-)
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Comment 7•18 years ago
|
||
Ah, nevermind. I see that this bug applies to 3.0, and the other bug applies to tip, and they're different enough now (that is, process_bug is so different between the releases) that they should have separate bugs.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: When email_in.pl call process_bug.cgi, no qa_contact field causes update failure → When email_in.pl calls process_bug.cgi in Bugzilla 3.0, no qa_contact field causes update failure
Updated•18 years ago
|
Component: Creating/Changing Bugs → Incoming Email
Updated•18 years ago
|
Component: Incoming Email → Creating/Changing Bugs
Comment 8•18 years ago
|
||
And yeah, we should definitely fix this before 3.0.4.
Flags: blocking3.0.4? → blocking3.0.4+
![]() |
Assignee | |
Comment 9•17 years ago
|
||
Rather than trying to fix process_bug.cgi and introducing unwanted regressions, I'm fixing email_in.pl to set qa_contact in all cases. If useqacontact is off, $bug->qa_contact is undefined and will be correctly ignored by process_bug.cgi.
Assignee: alex → LpSolit
Attachment #297761 -
Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #301160 -
Flags: review?(mkanat)
![]() |
Assignee | |
Updated•17 years ago
|
Whiteboard: [3.0.x branch only][3.2 not affected]
Comment 10•17 years ago
|
||
Comment on attachment 301160 [details] [diff] [review]
patch, v2
Okay. If you've tested this, this looks sensible.
Attachment #301160 -
Flags: review?(mkanat) → review+
Updated•17 years ago
|
Flags: approval3.0+
![]() |
Assignee | |
Comment 11•17 years ago
|
||
Checking in email_in.pl;
/cvsroot/mozilla/webtools/bugzilla/email_in.pl,v <-- email_in.pl
new revision: 1.5.2.6; previous revision: 1.5.2.5
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•