Bug 406221

Summary:	3.12: setpriority group membership necessary to altar priority of bug when creating or updating.
Product:	[Community] Bugzilla	Reporter:	David Lawrence <dkl>
Component:	Bugzilla General	Assignee:	Tony Fu <tfu>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	3.2	CC:	nelhawar
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-12 03:07:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	406071, 427051

Description David Lawrence 2007-11-30 16:58:17 UTC

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

Comment 1 Tony Fu 2007-12-20 02:57:04 UTC

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

Comment 2 Noura El hawary 2008-02-07 15:29:04 UTC

Hi Dave/Tony,

Also I think i can help with this bug.

Noura

Comment 3 David Lawrence 2008-02-11 21:48:29 UTC

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

Comment 4 Noura El hawary 2008-02-12 03:07:47 UTC

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 ***