OG User Roles: Notes

NOTES

• This module changes the "node/add" URL for creating new nodes in group context to "ognodeadd" which can cause problems with some other modules. We have fixed most of the problems that have arisen, and so far, we have tracked the known existing incompatibilities down to the following modules: editablefields http://drupal.org/node/175236 and Formfilter http://drupal.org/node/167184. However, you should be aware that you might be using a module which has this incompatibility with OG User Roles.
• Also, known problem with ognodeadd re-direction with CCK-created group content types where the machine-readable name contains dashes and the human-readable name contains spaces. http://drupal.org/node/178610
• Create content links on the main navigation menu: http://drupal.org/node/174959. In Menu settings, you should uncheck the "Expanded" option for the "Create content" menu item. If you leave the "Create links" menu option on "Expanded", then OG User Roles will display content types that the user can create here when the user is in a group where he has the appropriate role(s). However, if the user clicks on the "Create content" sub-menu link (rather than the Group menu "create" link), he will get an "Access Denied" message.

  This is as it should be since OG User Roles permissions should only apply to OG group content. However, to eliminate the irritation to your end-users, you should not have the Main navigation menu "Create links" expanded so users won't think they can create content from there.

• See notes on OG Forum: http://drupal.org/node/173568
• Hook provided to allow other OG modules to easily supply Group Node ID. http://drupal.org/node/176703
• Patched for compatibility with Relativity module. See: http://drupal.org/node/166253
• Compatibility with Content Type Administration by Organic Group module. See: http://drupal.org/node/177866. Also with Create Subgroups: http://drupal.org/node/334886
• Currently, there is a compatibility issue with the Drupal core upload module. Documented here: http://drupal.org/node/166566
• There was a reported incompatibility between this module and the BuddyList module. http://drupal.org/node/163873. There was a proposed patch for this issue here: http://drupal.org/node/166275#comment-287573. The issue was resolved by BuddyList maintainer: http://drupal.org/node/166275
• Please note that OG User roles and their permissions will only take effect within the specified group using the "Configure member roles" menu, Home->Groups->Your Group->Subscribers->Configure member roles. If you want a user to have the permissions of a role sitewide, then you must apply the role to the user's account in Admin->User management->Users
• Group Admin. When a user who is not the group creator is assigned to be a "Group Admin" for the group, we have noticed that the "Add subscribers" tab does not appear for this user when "og user roles" is installed. The fix for this is to:

  a. Create a "GroupAdmin" role in "access control", and give this role the "edit group content" permission.
  b. Go into "configure member roles" for the group, and give the Group Admin user the "GroupAdmin" role in this group; OR,
  c. You can go to OGUR Settings (http://drupal.org/node/163567) and check on the Default Group Role for new group administrator option. Select "GroupAdmin" role as the default role for new group administrators.

• Approve New Accounts. With respect to the Allow group admins to approve new signups setting:

  Requires the mimemail.module: http://www.drupal.org/project/mimemail

  If you click this setting on, then please note that if a new user elects to subscribe to multiple groups at signup, any group admin (who was the "administer users" permission) from any of the selected groups will be able to approve his account. This also means that any group admin (with this permission) from any group a user belongs to will be able to delete the user's account.

  Usage notes:

  • Group admins with the "administer users" permission will receive emails for new signups to their groups. These emails will have a link to URL oguseredit to edit ("approve / deny") the user account.
  • When the group admin has the "administer users" permission in his group, a "Manage users" tab will appear on the OG "Members" screen (og/users/$your_group_id). Clicking on this tab will allow the group admin to list all users in his group and edit their accounts.
  • When the group admin has the "administer users" permission in his group, a "Users" link will appear in the Main Navigation Menu. If the user clicks on this link he will get an "access denied" message. This is because this link is for sitewide user administration, and group admins only have the "administer user" permission within their groups. They need to click on the "Manager users" tab on their group "Members" page.
  • URLs for group admins (with "administer users" permission) to view users in a group (where $gid = Group ID):
    • ogusermanage/$gid
    • /og/users/$gid/manage

    URL for group admins (with "administer users" permission) to view an individual user in a group (where $gid = Group ID and $uid = User ID):

    • oguseredit/$uid/edit?gids[]=$gid
• Important: If you do NOT want a user or group of users to be edited using oguseredit, then you must give them the OGUR permission no oguseredit. User accounts which have either a site-wide or group role with the "no oguseredit" permission can NOT be edited using oguseredit.
• Also, very very important: If a user has a group role with the "no oguseredit" permission in any group he belongs to, his account will NOT be accessible using oguseredit. That is, if a user belongs to two groups, Group A and Group B. If the user has a role with the "no oguseredit" permission in only Group B, his account can NOT be accessed by oguseredit in either Group A or Group B (or any other group he belongs to).
• We have noticed that these URLs do not work unless the "Clear the cache" setting below is checked on. At this point, we don't know why.

You should only turn this setting on if you fully trust the group admins who have this permission to execute this privilege responsibly. You should NEVER give this privilege to group admins you don't know (e.g., self supported community sites where the group admin could be anyone).

You have been warned.