"Configure member roles" tab does not appear

Don't know why group members to whom you've assigned roles that have the "configure member roles" permission can not see the "Configure member roles" tab. Since this is a dummy site, may I log in to see what I can see? If so, use contact form to email me pertinent info.

If someone has just created a new group, then his role must shift from "Authenticated User" to "Group Founder" -- right?

OG User Roles never messes with a global (sitewide) role. But, if in OG User Roles settings, you have set a configuration for "Default Founder Role for users who create groups", then OG User Roles will automatically assign the user who creates a group to that role WITHIN the group he has just created.

And when as admin you do to Admin>>Users , in the "Roles" column, everyone still has no entries (not even "authenticated user"!!!), whereas some of them should be "Group Founder".

OG User Roles (that is, roles assigned to users using the "Configure member roles tab") NEVER show up in the Admin>>Users "Roles" column. Why? Because they are group specific roles, not global roles.

Now, I just tested the latest version of OG User Roles, and if "Default Founder Role for users who create groups" is configured correctly, then the user who creates a group is assigned to the "Founder" role automatically within that group.

Is this not happening on your site?

Going back to your reply, I did and checked everything about OG_User_Roles as it is outlined in read-me file and handbook. Still, in member listings the founder of the group does not show as "Group Founder" (the name that I gave), but as "Admin" (seemingly default name that comes with OG module).

My guess is that if Buddylist is preventing the display of "Configure member roles" tab, it is probably preventing the "founder" role from being automatically assigned to new group creator.

The code (in hook_nodeapi('insert')) is very straightforward:

        if (og_is_group_type($node->type)) {
          // Get the requisite data
          $uid = $node->uid; // user ID
          $rid = variable_get('og_user_roles_founder_value', 0);
          $gid = $node->nid; // group ID
          og_user_roles_role_join($uid, $rid, $gid); // assign user to group role in that group
        }

As you can see from above, the only way this will not work is if:

1. OG doesn't recognize the node type as a "group" type.
2. You did not select a "founder" role in OG User Roles settings.
3. For some reason, og_user_roles_join fails.

This, of course, assumes that you have checked the "Default Founder Role" checkbox in OG User Roles in the first place, which you indicate you have.

When it comes to privileges in all other aspects of Roles settings, I have configured these 4 extra roles in the same way as Authenticated user. Is this a correct way of doing it, or should I just have left all those checkboxes pertaining to Blogs and comments and other modules just blank??? This is the only other reason for OG_User_Roles mulfunctioning that I could think of.

If all authenticated users have certain permissions, I usually don't add them to OG User Roles since, by definition, the users who get these roles will already have the authenticated user role. But, doubling them up shouldn't hurt. But, I can't say for sure since I never do that. You can try removing the duplicated permissions from roles to see what happens.

I've created a mechanism for perfomring a little debug. Follow these instructions here: http://drupal.org/node/164038

It won't give us a lot of info, but it will tell us what role(s) the system has calculated for a user when he is on a particular page. So, if we see the correct "Configure member roles" role displayed for a user on "og/users/$gid", then we know OG User Roles is doing it's job, but something else is preventing the display. If we don't see the correct roles, then we know someting is preventing OG User Roles from doing it's job. Either way, we know more than we know now.

Oops. Sorry. The patch for the debug mechanism I referred to is here: http://drupal.org/files/issues/og_user_roles.module.5.x-2.1.patch

I don't have BuddyList installed, so unless you follow up on this issue, I'm going to close it because every test I run indicates that the "Configure member roles" tab does appear as it's supposed to in normal installations.

Unfortunately, don't have a solution for you. The mere fact that it "worked before" and now "sort of works" indicates an instability somewhere. But, what it is caused by and why, I don't have a clue.

So, let's look at the "Configure member roles" page:

og/users/(GID)/roles

If this page is being cached, if we can clear it, that would force OG User Roles to load the correct role(s) for the user.

So, to test this theory, please clear your cache (cache, cache_page?), then see if users can access the page.

Also, try the og_user_test debug table to see what you get back on this page.

If you don't already have it, download and install "Database Administration": http://www.drupal.org/project/dba.

Go to: Admin->Site Building->Database

Click on cache_page

See what urls are cached. See if one of those urls is the "Configure member roles" url.

Having exactly the same problem here: "Configure member roles" link didn't want to display. After reading this issue, I tried deactivating "Buddy list" module, and this "Configure member roles" link instantly re-appeared.
I tried debug, and I noticed that "og_user_roles_all_roles" still returns the complete appropriate list of roles, depending on user and group. Version of BuddyList is 5.x-1.0 .

Regards,
David

This is what's in og_user_roles_menu() (hook_menu). By normal Drupal standards, this should be enough to display the tab (assuming user has permission):

     ...
    // Add another tab to the group subscribers page for admins to
    // configure member roles
    if (arg(0) == 'og' && arg(1) == 'users' && is_numeric(arg(2))) {
      $gid = arg(2);
      if (og_user_roles_is_allowed($gid)) {
        $items[] = array(
          'path' => "og/users/$gid/roles",
          'title' => t('Configure member roles'),
          'callback' => 'og_user_roles_page',
          'callback arguments' => array($gid),
          'access' => user_access('configure member roles'),
          'weight' => 5,
          'type' => MENU_LOCAL_TASK
        );
      }
    }
    ...

Since I don't have BuddyList or use it or have any need for it, I would suggest you post this issue in the BuddyList issues. We just need to find out what it could possibly be doing that would prevent this tab from appearing on this page og/users/(GID).

I am assuming that:

a) The correct role(s) are returned in your og_user_test table for this URL, and;
b) At least one of the roles in question contains the "configure member roles" permission.

What you assumed is right in my case.
I followed here.

Anyone having this problem, please test the buddylist patch here.

Fixed here: http://drupal.org/node/166275