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.
Created attachment 297761 [details] [diff] [review] Fix to only define $formhash{'qa_contact'} when $qacontact is also deinfed
Confirming. This bug also occurs if you hack the URL and omit the QA field.
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?
Thinking about it a bit more, I wonder if I couldn't already hack the data to reproduce my testcase. Investigating...
You are most welcome to take the bug and fix it yourself :-)
*** This bug has been marked as a duplicate of bug 391669 ***
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.
And yeah, we should definitely fix this before 3.0.4.
Created attachment 301160 [details] [diff] [review] patch, v2 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.
Comment on attachment 301160 [details] [diff] [review] patch, v2 Okay. If you've tested this, this looks sensible.
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
or
