Bug 431346 - user accounts not picking up inherited permissions
Summary: user accounts not picking up inherited permissions
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: User Accounts   
(Show other bugs)
Version: 2.18
Hardware: All
OS: Linux
low
low vote
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-03 05:09 UTC by Jon Stanley
Modified: 2013-06-24 02:25 UTC (History)
3 users (show)

Fixed In Version: 2.18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-04 05:34:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jon Stanley 2008-02-03 05:09:22 UTC
qa_whiteboard, editbugs, and setpriority are all inherited permissions in the
bugzilla sense of the word from being in fedora_contrib from my understanding.

However, new contributors that are inserted into fedora_contrib via FAS are not
picking up these inherited permissions until an admin looks at the user, then
the user magically gets the permissions.  Note this conversation on IRC (jds2001
== me, abadger1999 == Toshio Kuratomi, ianweller == a user that was having issues):

23:21 < abadger1999> ianweller: and open up this page and tell me what's there: 
                     https://bugzilla.redhat.com/userprefs.cgi?tab=permissions
23:22 < ianweller> abadger1999: fedora_contrib is the only one listed
23:22 < abadger1999> ianweller: Okay. Looking
23:23 < abadger1999> ianweller: Refresh that page please
23:23 < abadger1999> Tell me if you have all four permissions now
23:24 < ianweller> i have all four now yes.
23:24 < ianweller> thanks :)
23:24 < jds2001> abadger1999: what did you do?
23:24 < abadger1999> jds2001: I think we're dealing with a quantum mechanical
bug :-)
23:24 < jds2001> lol
23:25 < abadger1999> If I look at the permissions in the admin page they
suddenly get the proper permissions.
23:25 < jds2001> hmmm
23:25 < abadger1999> (I don't change anything.  Just look the user up and then
click onto their page to see what's there.)

Comment 1 Noura El hawary 2008-02-04 04:01:51 UTC
I tested this issue and yes the permissions of the user don't get updated until
an admin views the user's page using editusers.cgi, basically this issue is
caused by updating user's permissions using the xmlrpc function
Admin.updatePerms(), the function is missing couple of lines to refresh and
derive the user's groups after updating their permissions, editusers.cgi has
those lines that is why the permissions gets refreshed there. attaching a patch
with the fix for a review. 

Thanks for reporting the issue.

Noura

Comment 5 Noura El hawary 2008-02-04 05:34:13 UTC
a patch to fix this problem has been committed to cvs , it should be live when
the next bugzilla package is pushed to production which on the latest will be
this Thursday.

Noura

Comment 6 David Lawrence 2008-02-06 19:22:12 UTC
This change is not on production server. Please reopen if there are any problems.

Dave

Comment 7 Jon Stanley 2008-02-06 19:46:55 UTC
"not" or "now"?  I assume the latter.

Comment 8 Noura El hawary 2008-02-07 00:31:18 UTC
now for sure lol.


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