Rename "site administrator" role to "administrator"

Let's keep the default D7 'administrator' role, because we need it for true administrative duties. The 'site administrator' is designed to be a safer set of permissions which can be handed out to any novice without allowing them to destroy the entire site.

But, we should change the 'site administrator' role's name to 'site maintainer' because it more closely resembles the true nature of the role, and it'll better discern the difference between the two "power" roles.

Patch forthcoming.

This patch renames the 'site administrator' role to 'site maintainer' in order to differentiate it from the default D7 'administrator' role.

Tested the patch above. Only found this issue:

Checking patch cod_community/cod_community.features.user_permission.inc...
error: while searching for:
  $permissions['administer site-wide contact form'] = array(
    'name' => 'administer site-wide contact form',
    'roles' => array(
      '0' => 'site administrator',
    ),
  );

cod_community version 7.x-1.0-dev was change to:

  $permissions['administer contact forms'] = array(
    'name' => 'administer contact forms',
    'roles' => array(
      0 => 'site maintainer',
    ),
    'module' => 'contact',
  );

Attached is the updated patch.

tested and reviewed and see that the patch renames the 'site administrator' role to 'site maintainer'.

I have also tested this patch, applies clean.

title update

I'm just updating the title to match the case of the change (i.e. all lower case). I'm not sure if there is a standard for these in D7, but at least there is consistency in all lower case on this text in both versions.

Tagging.

A) Explain why we need a sub-administrative role versus the targeted admin roles we already have and provide a specific example of how it would differ from the primary administrative role.

The targeted admin roles leave a gap where we need an user to have access to sensitive info (commerce), but not have access to things which could pose a security problem (php filter, administer permissions).

C) Ideally provide a title for the site maintaner role that more clearly distinguishes it from the primary administrative role. A) would help with that.

conference administrator …?

or D) Simply revise the patch to provide some sane defaults for the existing administrator role that ships with core, as proposed in the OP.

I have seen a need for multiple users with unrestricted access to administrator features, so IMO a 'safe' admin role is needed, not just modifications to the core admin role.

I am not clear of our action item here. Are we good to just change the name to "conference administrator" ?

I agree with twardnw: There are instances where volunteers should be able to help handle conference related tasks - scheduling events, posting blogs, etc. But, these people oftentimes should not have access to sensitive data, such as reports living in Commerce.

Conference Administrator or or Conference Manager would be good names.

+1 for conference manager

if we need a conference manager, then we might also need to consider to add the following:
Administer content
Schedule a Schedule Item
Schedule a Session
Schedule a BoF Session
Access other users' private fields? for field permissions?

then sub modules can use this role to add their permissions.

Yes, each component should be adding it's own set of permissions to the role. For cod_base I think it should be:

• access admin toolbar
• administer blocks
• administrer comments
• administer features(?)
• manage features(?)
• use full html
• administer menus
• administer content
• access content overview
• view own unpublished content
• view content revisions
• revert content revisions
• create article
• edit any article
• create basic page
• edit any basic page
• administer url aliases
• create\edit url aliases
• administer modules (?)
• administer site configuration (?)
• administer themes (?)
• use admin pages
• view admin theme
• administer users
• administer views

The few that are marked with a ? I am not sure of, in all likelihood those items are established and maintained by the users of the Administrator role, as those things hold implications on site functionality.

title update

The features says overridden but everything is in 'default' mode so I'm not sure what's wrong. I'm attaching my patch here.
Regarding the patch, I only based the permissions on the cod_base so some of the mentioned permisisons in #15 are not applicable. here is the full list of permissions in this patch:

• Administer text formats and filters
• Administer menus and menu items
• Administer content
• View published content
• Use the administration pages and help
• Administer users
• View user profiles
• Administer views

Features, themes and site configuration, I don't think they are necessary to administer the conference details.

Patch works on my end. I see the permissions listed above enabled for the role "Conference Administrator" and that this role was renamed from "Site Administrator".

The overridden thing I think is because of "administer site configuration". `drush fd cod_base` says:

Component: user_permission
      'roles' => array(
        0 => 'conference administrator',
>     ),
>   ),
>   'administer site configuration' => array(
>     'module' => 'system',
>     'name' => 'administer site configuration',
>     'roles' => array(
>       0 => 'administrator',
      ),
    ),

Maybe because of this part:

-  // Exported permission: administer site configuration
-  $permissions['administer site configuration'] = array(
-    'name' => 'administer site configuration',
+  // Exported permission: administer menu.
+  $permissions['administer menu'] = array(
+    'name' => 'administer menu',

Patch attached for the permission "administer site configuration" removed in the feature since it isn't used in cod_base.

looks really good, only thing I would take off is Administer Text Filters, patch attached.

Looks like #21 is clean and adds all of the permissions discussed here, with the exception of Administer Text Filters.

looks good here as well.

tested the patch as well on #21 and it is good and applies cleanly.

I think we need to hold off on this patch, its very important that the 'conference administrator' does not have the Site Admin privileges (as mentioned by the Security Team via Ezra)

I'm also in the camp of "make roles that are sufficient for the tasks that need to be done" and then checking them off. IE: Session Manager, Commerce Manager, Sponsor Manager, forum Manager, etc.

We need to come up with compelling roles for each 'task' that needs to occur, then assign people those roles.

--needs work--

Looks good, cod_base when reverted shows as default. Requires Features 7.x-1.0 to not show up as overridden, and is the core administrator role (not the conference admin).

Also for site-wide content administration and other needed roles, we should be looking at adding 'per task' roles to each feature. Look at content manager role as the other role that should be included with cod_base.

http://drupal.org/node/1673028