Bug 406221 - 3.12: setpriority group membership necessary to altar priority of bug when creating or updating.
3.12: setpriority group membership necessary to altar priority of bug when cr...
Status: CLOSED DUPLICATE of bug 406141
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
All Linux
high Severity medium (vote)
: ---
: ---
Assigned To: Tony Fu
Depends On:
Blocks: RHBZ30UpgradeTracker 427051
  Show dependency treegraph
Reported: 2007-11-30 11:58 EST by David Lawrence
Modified: 2013-06-24 00:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-11 22:07:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2007-11-30 11:58:17 EST
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-19 21:57:04 EST
Size estimation:

if (($field eq "priority") &&
            return 0;
code to implement this function in relevant files (post_bug.cgi process_bug.cgi
Bugzilla/Bug.pm Bugzilla/RPC/Bug.pm).  

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 10:29:04 EST
Hi Dave/Tony,

Also I think i can help with this bug.

Comment 3 David Lawrence 2008-02-11 16:48:29 EST
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 %]
  [% 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 %]
        [% END %]
    [% ELSE %]
      <input type="hidden" id="[% selname %]" name="[% selname %]" value="[%
bug.${selname} FILTER html %]">
      [% bug.${selname} FILTER html %]
    [% END %]
  [% IF NOT no_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

What do you think?

Comment 4 Noura El hawary 2008-02-11 22:07:47 EST
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.


*** This bug has been marked as a duplicate of 406141 ***

Note You need to log in before you can comment on or make changes to this bug.