Hi Eric,

Today, there isn't anything for that. You can work around this by
patching reviewboard/admin/views.py to have site_settings check
request.user.is_superuser and return some sort of result (redirecting
to the login page, or something), and patching
templates/admin/base_site.html to add {% if user.is_superuser %} ...
{% endif %} around the link for Settings.

Our main priority with the upcoming Review Board 1.6 release is to add
more fine-grained access to the site. What's in right now is the
ability to restrict access to review groups and repositories (which
then affects review requests). We also need to provide finer-grained
restriction to the admin UI. This will include settings.

Now I haven't quite worked out how best to do this. Depending on how
you're using Review Board, you may want to restrict access to all
settings for everyone but the superuser, but you also may want to
allow it for a select set of non-superusers. The reason for this is
that the 1.6 release will allow partitioning Review Board into a bunch
of separate virtual installs ("local sites"), all running off the same
database and software. This would allow you to, say, provide a Review
Board install for developers and one for QA and one for UE, all
separated with their own groups and such. In such a setup, maybe each
one has its own set of admins that shouldn't be global superusers, and
maybe they should have control over *some* settings but not others.

So, we need to figure that out. And none of that will help you until
1.6 (unless you want to try betas as they come out), but since it
sounds like you're partitioning responsibilities like this already,
getting your input is very helpful.

Christian

--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com



On Wed, Nov 17, 2010 at 6:43 PM, Eric Johnson
<ericjohn...@alumni.brown.edu> wrote:
> I'm struggling with a particular configuration problem.
>
> I've got three classes of users... Ones that can work on reviews, ones that 
> can do anything (superusers), and ones I want to restrict to being able to 
> muck around with the admin/database models for changesets, diffs, and reviews.
>
> The "Staff" setting is almost perfect for this in-between role, in that it 
> appears that I can set up a group that staff members belong to, and give 
> specific permissions to them.  Notably, I can prevent them from changing 
> authorization config, scmtools, sites, and siteconfig. That fixes everything 
> under ./admin/db area, however, the staff members can still see the 
> ./admin/settings/... URLs, and even change them.
>
> Is there any way to block the settings (general, authentication, e-mail, ... 
> ) from staff users? Or at least prevent them from making changes? I've been 
> digging around the code, and haven't figured it out.
>
> I'm okay with making patches to my local copy, if that's what it takes.
>
> Eric
>
>
> --
> Want to help the Review Board project? Donate today at 
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to 
> reviewboard+unsubscr...@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/reviewboard?hl=en

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to