Red Hat Bugzilla – Bug 406221
3.12: setpriority group membership necessary to altar priority of bug when creating or updating.
Last modified: 2013-06-24 00:19:48 EDT
Description: Users who are not in the setpriority permission groups are not allowed to update the severity value for a defect/feature report. Most Red Hat employees are in this group and should be able to edit the attribute. Also the data/params value for letsubmitterchoosepriority to false. Function Requirements: post_bug.cgi process_bug.cgi Bugzilla/Bug.pm Bugzilla/RPC/Bug.pm
Size estimation: Add if (($field eq "priority") && !Param('letsubmitterchoosepriority')) { return 0; } else code to implement this function in relevant files (post_bug.cgi process_bug.cgi Bugzilla/Bug.pm Bugzilla/RPC/Bug.pm). LOC=3*4=12 Test unit Need to test processing three pages, each need average 20 lines of testing code. Also a xmlrpc call need to be tested, which in average needs 100 LOC. Total LOC = 12+20+100=132
Hi Dave/Tony, Also I think i can help with this bug. Noura
Noura, I think this is already implemented for us with the Bugzilla::check_can_change_field() function. I was testing the patch for the rhel change restrictions patch in bug 406141 and I noticed that when I was logged in to a bug with limited permissions, the "priority" field was read only. I looked at the edit.html.tmpl template and I noticed that it was calling bug.check_can_change_field() for that select. [% BLOCK select %] [% IF NOT no_td %] <td> [% END %] [% IF bug.check_can_change_field(selname, 0, 1) AND bug.choices.${selname}.size > 1 %] <select id="[% selname %]" name="[% selname %]"> [% FOREACH x = bug.choices.${selname} %] <option value="[% x FILTER html %]" [% " selected" IF x == bug.${selname} %]>[% x FILTER html %] </option> [% END %] </select> [% ELSE %] <input type="hidden" id="[% selname %]" name="[% selname %]" value="[% bug.${selname} FILTER html %]"> [% bug.${selname} FILTER html %] [% END %] [% IF NOT no_td %] </td> [% END %] [% no_td = 0 %] [% END %] Since inside the template it passes in a 0 and 1 as the new and old values, the function will always treat the field as if it is being changed. Then whether check_can_change_field returns a true/false value, it will make the select read only or editable. So since we have a check for a person being in the 'setpriority' group in the patch for 406141 then this is helping us with this bug as well. If you concur with this, then we can probably close this as a duplicate of bug 406141. What do you think? Dave
Hi Dave, I agree with you. I also noticed how the priority/importance was disabled for users who are not in setpriority group when i was testing your patch. So i will close this bug as duplicate as you said. Thanks, Noura *** This bug has been marked as a duplicate of 406141 ***