I am proposing to change the access argument used for accessing the PRLP configuration to a PRLP-specific permission.
Currently, the access argument used is "Administer Users". I can see how PRLP falls into that umbrella of user administration. However, there can be a case where a Site Owner needs to administer users (change user roles, block users, etc...) but does not need to administer PRLP configuration.
By using a separate PRLP permission, a Site Owner can still be allowed to administer users, and be denied access to the PRLP config form. This cuts down on the available admin menu links (granted, it adds another permission to the permissions table).
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | prlp-add_hook_permission-2572237-1.patch | 837 bytes | Jukebox |
Comments
Comment #2
Jukebox commentedComment #3
jitesh doshi commentedI apologize that I have to disagree on this. I feel that "administer users" is the appropriate permission. If you're able to administer users, then you're also able to change their passwords by hand. In that case, why shouldn't you be able to administer PRLP?
May be yours is a special case. And I respect that. But most people would fall in the general case where anyone who can administer users, should be able to administer PRLP.
If you feel really strongly about it, then please re-open this, and submit patch that includes a hook_update_N implementation as well which copies "administer users" grants into "administer PRLP" as the initial value, so that this doesn't break backward compatibility for all existing users (the general case).
Comment #4
winn commentedJitesh, I would like to open up this discussion again. I believe that often times, a non-technical site admin should be able to administer users, but should not have the ability to configure the website. This is not necessarily that they shouldn't have the permission to administer PRLP, but that they are most likely not experienced in site configuration, and really shouldn't be messing around with PRLP settings.
I believe that administering PRLP falls into the category of site configuration, as opposed to managing content and users. Below are some examples of other modules that take a similar approach. In each example below, the first permission represents a permission that a site owner would most likely need, whereas the second permission represents a permission that should be reserved for experienced site builders or developers:
Node > Administer content
vs
Node > Administer content types
Page manager > Use Page Manager
vs
Page manager > Administer Page manager
User > Administer Users
vs
User > Administer permissions