OG User Roles

Yes, if someone will direct me to how I can create a patch. I haven't a clue.

Here's the patch. Please keep in mind the following:

1. This patch is for the user.module for version 4.7
2. The permissions will work only for domains like this: www.domain.com and NOT like this: www.domain.com/folder
3. The table og_users_roles MUST already exist in your Drupal database.
4. Don't forget to that og_user_roles.module must be installed and used to assign roles to users by group. Right now, I'm not sure if it will co-exist with og_roles.module.

That's all I can think of. I'm sure something else will come up, and if so, please post. Thanks!

Well, what you are describing is handled by roles. Your role in a group may be as "contrib", that is, you can enter content in the group. You could invite your friend to join, and his role in this group would be "member", that is, he can access content but cannot enter any content in this group.

og_roles works fine with this. The problem is, if you have more than one group on your site, then your role is "contrib" for every group in the site. Same is true for your "member" friend.

The module I wrote addresses this weakness by limiting the permissions granted/denied by a role to a specific group. So, now, you can be "contrib" in group A, but "member" in group B. Same for your friend who will be "member" in the first group, but perhaps "contrib" in another.

If you don't care what roles users have in your groups, then the module I wrote doesn't affect you. If it's ok that users have the same roles in all groups, then it doesn't affect you. If you are willing to create different role sets for different groups, then what I wrote doesn't affect you.

Make sense now?

Also, what I wrote is not an official contribution nor is it sactioned anywhere by anyone. I wrote it to resolve the roles issue on my site, and put it up here for feedback. It is designed for folks who understand both Drupal and og very well, and know exactly the role structure they wish to have within groups.

I haven't followed up on it. The only thing I see to do is either make it a part of og_roles module, or create a new module myself. And, the module I create would simply be the og_roles module with my enhancements. I've never created a module for public use before, so you can imagine my hesitance.

Need some help.

I along with another Drupal administrator have tested this module, and for the most part it is working. We have run into one problem. Here's the scenario:

There are two roles created: publisher and member. When a user is assigned to a group, he is assigned either the publisher or member role. Only publishers can create content.

The list of content items that the publisher can create shows up perfectly on the group menu (this means my user_access() modification is working). However, when the publisher clicks on a group menu create content link, he gets "Access Denied". I looked around and could not find anything wrong with the logic in my program. So, I wrote a little debug snippet to write out to a file the value that the user_access() function (that, is, "user_access($string_value)") receives.

<code>
function user_access($string, $account = NULL) {
  global $user;
  static $perm = array();

  if (is_null($account)) {
    $account = $user;
  }

  // User #1 has all privileges:
  if ($account->uid == 1) {
    return TRUE;
  }

  // To reduce the number of SQL queries, we cache the user's permissions
  // in a static variable.
  if (!isset($perm[$account->uid])) {
//
// Modified this to call user_all_roles();
//
    $result = db_query("SELECT DISTINCT(p.perm) FROM {role} r INNER JOIN {permission} p ON p.rid = r.rid WHERE r.rid IN (%s)", implode(',', user_all_roles($account)));
//
    $perm[$account->uid] = '';
    while ($row = db_fetch_object($result)) {
      $perm[$account->uid] .= "$row->perm, ";
    } // end while
 
// my debug snippet goes here  It prints out the $string value sent to user_access function //

  } // end if
  if (isset($perm[$account->uid])) {
    return strpos($perm[$account->uid], "$string, ") !== FALSE;
  }
  return FALSE;
}

My debug program is showing me the "administer cac_lite" permission. I have no idea why, but when I granted all authenticated users the "administer cac_lite" permission, the access denied problem goes away for user roles in groups. It works perfectly, giving and denying access to content based upon the role(s) assigned to a user in a specific group.

As if this wasn't bad enough, the other Drupal user who was experiencing the same problem ran my debug snippet, and it is the "maintain buddy list" permission showing up in his log. When he granted all authenticated the "maintain buddy list", then the problem went away for him as well. My modification works exactly as it is supposed to, granting permissions to users based upon roles that are restricted by group.

I asssume there is something about the way I modified user_access() that causes it to hang on these particular permissions.

I know this is pretty deep, but can someone give me a clue as to what the problem might be here? Resolve this, and this program is good to go. Thanks.

-ron

As the author of this modified code, I wholeheartedly agree. I did not want to modify the user.module. I posted a number of messages asking questions about how permissions and roles worked, but rarely received any answers.

So, I went about the task of trying to figure out how to accomplish this goal on my own. The key, as far as I could tell, was the user_roles table. Needed another table to define what roles a user would have in each group. And, finally, needed a way to grant permissions based upon roles in this table. The only way I saw (and see) to do this was in the user_access function in the user.module. Since there was no "hook", the module had to be modified directly.

So, if we could get Drupal to implement user_access as a "hooK', our "hacking core code" problem is solved.

And, by the way, I finally solved the last problem to my modification -- the one which was causing it to incorrectly identify permissions from the cache. Essentially, all I had to do was remove the "isset" test for the cache, and simply re-create it each time. Not efficient, but it does the trick. Since a user's permission can be different depending upon the content's group, what I now need is some way to tell user_access to only update the cache if the group has changed. For another day. Right now, however, the code is working perfectly.

That modification is attached.

If someone has a better idea or approach, I'm all ears. However, my code is working now for 4.7.

OK, this is the version of the user.module I modified (version 4.7):

// $Id: user.module,v 1.612.2.10 2006/05/23 09:39:47 killes Exp $

Attached is the patch. Please note from #4:

Here's the patch. Please keep in mind the following:

1. This patch is for the user.module for version 4.7
2. The permissions will work only for domains like this: www.domain.com and NOT like this: www.domain.com/folder
3. The table og_users_roles MUST already exist in your Drupal database.
4. Don't forget to that og_user_roles.module must be installed and used to assign roles to users by group. Right now, I'm not sure if it will co-exist with og_roles.module.

When a user attempts to create a new node:

http://drupalsite.com/node/add/flexinode-3?edit[og_groups][]=71

What permission function(s) are executed?

user_access?
node_access?
og_basic_access?

And, in which modules?

My user_access function is working correctly, but apparently when the above command is executed, some other permission checking is executed. If I could find out what, I could probably solve this for good.

Thanks so much for any assistance anyone can provide.

-ron

Oops. I accidently changed the titled of this thread. Sorry.

I've not given up. Attached is my latest patch to the user.module. It is designed to be applied to the original Drupal 4.7.5 user.module. Same requirements for og_user_roles.module as defined at the top of this thread.

My modification is more or less working. The one problem we've ran into is on node creation, you sometimes get "user access denied" error if you have logged in previously using the same browser but with a different account. The user_access function I modified actually works every time, with the exception of this potential problem, and even this is only on node creation. The problem is resolved by clearing the cache and running cron.php.

The only symptom I've been able to find is that when the "access denied" error occurs, the user_access function is unable to read the default drupal "arg" values. In other words, I created a test to output to a test file the values that are in user_access each time it is called. When the program fails on node creation, it is always unable to read the value of "arg(0)". So, my educated guess is that the user_access function is losing the group or node context under this circumstance. If it loses the group context, then it can't very well determine the user's group role(s). Maybe someone will understand why this is happening.

At any rate, I put into the patch I have attached code to write to a test file called "user_test" the values that user_access receives each time it is called. This is purely for debugging purposes. The command to create the user_test file:

//
// Create Table Test
//
CREATE TABLE user_test (
  testDate varchar(25),
  testUser varchar(5),
  testUserName varchar(40),
  testFunction varchar(60),
  testSubFunction varchar(80),
  testString varchar(60),
  testStatus varchar(10),
  testURI varchar(200),
  testAArg0 varchar(40),
  testAArg1 varchar(40),
  testAArg2 varchar(40),
  testAArg3 varchar(40),
  testPerm long varchar
) 

Finally, I came up with a way to assure that there is never a permissions issue with node creation using my modified module. I created code for my own "node/addform" node. All I did was:

1. Create a page node (all user roles should have access to it) with the following php code:

//
// node/addform is alias for my node/145
// You should alias whatever node you create using this code to:
//
// node/addform
//

global $user;
$account = $user;

 $type = $_GET['type'];

 if (user_access('create '. node_get_name($type) .' content')) {

   $output = node_add($type);
   return $output;
 }

2. Created an alias for this new node called "node/addform". In other words, if the page node I created is "node/145", I create an alias to it called "node/addform".

3. Now, when I want to create group content, instead of this command:

	http://drupalsite.com/node/add/flexinode-3?edit[og_groups][]=72

I use this command:

	http://drupalsite.com/node/addform?type=flexinode-3&edit[og_groups][]=72

So, if for whatever wacky reason, the "user_access" function loses the group context as a result of whatever permissions checks, my program is designed to still get it and verify the user's group role access. The result is that the permissions are checked correctly every time, regardless of how many times you log in and out as various users.

The og.module automatically creates the group node creation urls. If you are able to use my og_user_roles.module without incident, then use the default menus. If not, then you'll have to create your own custom menus for group content creation.

I think that's it for now.

Here is my modified 'addform' code. I forgot to mention that you may need to modify the code for node types that aren't captured by it now. I created the code this way because I primarily use flexinode content types for my groups, but needless to say, your cases may differ.

//
// node/addform is alias for my node/145
// You should alias whatever node you create using this code to:
//
// node/addform
//

global $user;
$account = $user;

 $type = $_GET['type'];

 if (user_access('create '. $type)) {
   $output = node_add($type);
 }

 if ($type == 'book') {
	if (user_access('create book pages')) {
		$output = node_add($type);
 	}
 }

 if ($type == 'forum') {
	if (user_access('create forum topics')) {
		$output = node_add($type);
 	}
 }

 if (strpos($type, 'flexinode') !== false ) {
	if (user_access('create '. node_get_name($type) .' content')) {
		$output = node_add($type);
 	}
 }
 
 return $output;

You are right. og_roles module isn't used at all.

og_user_roles is the new module name. Everything that was og_roles was changed to og_user_roles.

No conflict with user_roles() or _user_roles().

Version 5.0? I barely got it working on 4.7!

I think what I need to do first is see if I can get it to work in 5.0. Who knows? Maybe it will be easier. If so, then I guess I'll go ahead and try to make it a separate project. You are right: It should not co-exist with the existing OG Roles, and it is too confusing to have both anyway.

Yes, it does need it's own table because that was the simplest way to get it to work with the user_access function (although I put all the code into the user.module, there is only really one line that needs to change). Also because the module creates a new paradigm for permissions (requiring that they be determined by both Role AND Group instead of Role alone). Doing this without a new table would require massive changes to the user_access function, and I simply wanted to stay away from that.

Anyway, I'm starting to familiarize myself with 5.0 now. If I can implement this in 5.0, I will. In any event, I agree that trying to merge with existing OG Roles is not a good idea.

Thanks for the feedback.

I'm just about ready to go with this as a 5.x module, just have one problem that continues to haunt:

The only symptom I've been able to find is that when the "access denied" error occurs, the user_access function is unable to read the default drupal "arg" values. In other words, I created a test to output to a test file the values that are in user_access each time it is called. When the program fails on node creation, it is always unable to read the value of "arg(0)". So, my educated guess is that the user_access function is losing the group or node context under this circumstance.

Further testing shows that the function is not losing the group context. That, surprisingly, is maintained. All other variable values as well, such as permissions, roles, etc... What's disappearing are the arg() values, and that is apparently a symptom of the problem in that it only happens when access is (incorrectly) denied.

Can anyone give me a clue as to why the user_access function would lose the arg() variables? I bring back the same table $user->roles does, only with any additional group roles.

Thanks for any clues.

I cannot tell you how much I would appreciate the help. I tried to attach the .gz file I created, but that type is not allowed here.

For the time being, I have uploaded it here: http://ftp.scbbs.com/pub/drupal/og_user_roles/og_user_roles-5.x-1.x-dev....

The first problem I ran into when I tried to install it is that the og_users_roles table wasn't automatically created. Don't know if I didn't create the .install file correctly.

Please let me know what you think of the README.txt and everything. It's my first time doing this so I'm a complete newbie. Also, if someone could give me some advice on beginning this as a project.

Please let me know if there are any questions you have!

Thanks!

I want to say "yes", but that would be assuming I know everything there is to know about Drupal, and that is far from the truth. I don't know how you would make it work using node_access, particularly since:

a) node_access calls user_access
b) node_acess is not used for permisisons in node listing (node_db_rewrite_sql is)

With respect to node_grants, let's take the taxonomy_access_node_grant:

/**
 * Implementation of hook_node_grants()
 * Gives access to taxonomies based on the taxonomy_access table
 */
function taxonomy_access_node_grants($user, $op) {
  return array('term_access' => array_keys(is_array($user->roles) ? $user->roles : array(1 => 'anonymous user')));
}

This function uses $user->roles. But, how does it get the additional role(s) this user may have in this particular group? We have to now modify this function as well.

However, by adding the appropriate roles to user_access, you get the correct grants when listing/creating/updating/modifying.

Of course, if I'm wrong, I'm more than happy to know where and how.

Modifying node grants seems to make sense, but remember that my paradigm is radically different from the existing Drupal permission schema. I'm not just giving a user a role, but giving the user a role within the group context that the user is currently in. In other words, if the Drupal permission schema is curently three dimensional, I'm adding a 4th dimension (time/space). Neither the node_access or term_access tables are currently designed to accomodate this additional restriction (you have a certain role, and therfore certain permissions, if you are in a certain group at the time you execute this function)

After exchanging notes on the developer list, I figured what I really need to do is propose a hook for user_access. What I found with my user_access modification is that it works practically everywhere EXCEPT node creation.

I actually modified node_db_rewrite_sql() (as a test) to respect the additonal roles provided by og user roles. No change. Remember the node_db_rewrite_sql() hook is primarily for node listing, not node creation.

My user_access modification works for listing/updating/deleting but not creating (at least default node creation using node/add).

I am able to create nodes with it by calling the node_add function directly. I created a node which contains php code that does a user_access permission check, and if the user has the "create" permission for the content type, it then executes node_add(content_type) to create the new content.

So, if user_access is returning the permissions, the question still remains: why does the default /node/add fail? That remains the last piece of the puzzle to resolve.

FYI, the code for that "content submission" node is below. I'm only using 3 document types with og user roles, so those are the only ones the code currently processes. I give the node the url path alias "node/addform", and construct the url like this:

http://www.mydrupalsite.com/node/addform?type=document&gids[]=12

// 
// Content Submission Code (Version 5.x)
//
// Put this in the node you will call for creating nodes using og user roles.
//
// node/addform is alias for my node/20
//
// You should alias whatever node you create using this code to:
//
// 		node/addform
//

global $user;
$account = $user;
$gids = $_GET['gids'];
$typeFound = 'no';

//
// First, get the group ID and set the group context in case it's not already set
//
	if ($gids) {
	   $group_node = node_load($gids[0]);
	   og_set_group_context($group_node);
	}

//
// Get the content type
//
	$type = $_GET['type'];

if ($type) { 

 if ($type == 'forum') {
   if (user_access('create forum topics')) { // This is my modified user_access which determines permissions based upon group role(s)
     $typeFound = 'yes';
     $output = node_add('forum');  // this always works
   }
 }

 if ($type == 'event') {
   if (user_access('create events')) {
     $typeFound = 'yes';
     $output = node_add('event');
   }
 }

 if ($typeFound == 'no') {
   if (user_access('create '. $type . ' content')) {
     $typeFound = 'yes';
     $output = node_add($type);
   }
 }

}

 return $output;

Really appreciate the response. Got me to hoping that perhaps it might be the solution to my problem.

Remember the problem: User is given role by og user roles that allows him to create a content type, let's say "document" here. The "create document" link appears in his group menu. When he clicks on that link, he gets "access denied". The link is node/add/document?gids[]=29

My user_access modification has granted the user the "create document" permission in this group according to his role in this group.

So, user gets "access denied" message when attempting to create content that user_access grants him permission to create. If I am understanding you correctly, you are suggesting that this problem could be resolved by adding the necessary grants using the node_grants hook.

Below is the code which invokes the node_grant hooks in node_access:

  // If the module did not override the access rights, use those set in the
  // node_access table.
  if ($op != 'create' && $node->nid && $node->status) {
    $grants = array();
    foreach (node_access_grants($op) as $realm => $gids) {
      foreach ($gids as $gid) {
        $grants[] = "(gid = $gid AND realm = '$realm')";
      }
    }

Note the key phrase here:

$op != 'create'

Since the node_grants hook is only accessed here in node_access, and NOT for a create operation, theoretically, it would have no effect this particular case, even if I did use it. Or, am I missing something?

I hope so, because I would really like to find a solution to this. And, if there is a solution, what would the grant I need to add via a node_grant hook look like?

Don't have problem with node edit, just node create. Which is why I created my own content submission node (posted above).

In og I did this:

function og_og_create_links($group) {
  foreach (node_get_types() as $type) {
    $exempt = array_merge(variable_get('og_node_types', array('og')), variable_get('og_omitted', array()));
    if (!in_array($type->type, $exempt) && node_access('create', $type->type)) {
//      $links[] = l(t('Create !type', array('!type' => $type->name)), "node/add/$type->type", array('title' => t('Add a new !s in this group.', array('!s' => $type->name))), "gids[]=$group->nid");
//
// Modified to use addform (custom node creation node)
//
      $links[] = l(t('Create !type', array('!type' => $type->name)), "node/addform", array('title' => t('Add a new !s in this group.', array('!s' => $type->name))), "type=$type->type&gids[]=$group->nid");
    }
  }
  return $links ? $links : array();
}

Needless to say, I'd like to figure out why node/add fails.

Also, I want to re-interate that individual calls to node_access() and user_access() by users in og user roles for content they should have access to actually succeed. It's just the node/add process that fails.

More than a couple times on this list and elsewhere I have asked for someone to please help me figure out what happens in the node/add process that would prevent my modification from working. Never, not once, have I ever received a response to that question. I guess it's because everyone else knew what I didn't: There is a debug module which will show you everything that a particular command is doing.

I've found it, and I think it's going to help me resolve my problem. I just wanted to share it with those of you who may never have heard of it (like me, until recently).

Devel: http://drupal.org/project/devel

A great module for Drupal developers to have.

No CVS yet because still have the issue of user.module modification to resolve. I'm going to propose some sort of hook to add roles provided by module to those obtained in user_roles function. That would do the trick.

The latest og_use_roles module is here:

http://ftp.scbbs.com/pub/drupal/og_user_roles/

I've tested it and it appears to be working fine.

Please let me know any comments you may have. Thanks.

First off, this is not an official project. The whole module depends upon a patch to core. I need to propose some sort of user_access hook for this module to work without any core modifications.

Secondly, I am not supporting the 4.7 version of this module. Yes, the original module was written in 4.7, but I was never successful in getting it to run without having to use an alternative method for creating group nodes. I have been successful in 5.x, so that's what I'm sticking with.

Sorry for the trouble.

The developer of og said he was not interested in "exotic" forms of access control like this. The current manager of og roles and I agreed that these are two totally different modules, and should not be combined. There have been offers of assistance, but the biggest help I need is in folks just using the module to find where the problems may be.

Outside of that, a little help with defining the hook proposal would be useful. Right now, the basic og user roles hook proposal is this:

a. We need a way for a module to add permissions to $perm[$account->uid] in this operation in the user_access function:

  if (isset($perm[$account->uid])) {
    return strpos($perm[$account->uid], "$string, ") !== FALSE;
  }

OR;
b. We need a way for a module to add roles for a user to the result of this operation anywhere it is called:

$user->roles

Either one of these would accomplish what we need, although I believe b. would be the most efficient way to handle it. The modification I have now actually replaces $user->roles in the user_access function.

Submitted proposal to add hook_roles feature to Drupal core here: http://drupal.org/node/143393

I need some help. I have basically solved the problem of patching the core user.module for og_user_roles to work.

I was able to re-write the module to use the hook_user "load" operation to add the group roles to $user->roles when it is called in user_access. It's working. However, as I describe here: http://drupal.org/node/143393, I'm getting the same error message on group node creation that I got when I patched user_access: "Access denied".

So, what I really, really need now is to know what else, besides user_access (and $user->roles) would be used to determine a user's permissions on a group node creations such as:

http://www.mysite.com/node/add/link?gids[]=29

Something in the node.module, the og.module?

I solve this, and the module is good to go -- with no core hacking!

Looks like I've finally cracked this nut. I'll post notice when I've incorporated this modification into the distribution I've made available.

I had to do an end-around to do it, but I've finally come up with an implementation that doesn't require modifying other modules.

From the very beginning, the only circumstance in which my og user roles module failed was in node creation, specifically node/add/type?gids[]=gid. To solve this problem, I simply created code that would check the user access and call node_add directly:

function og_user_roles_addform() {
  global $user;
  $gids = $_GET['gids'];
  $typeFound = 'no';
   if ($gids) {
       $group_node = node_load($gids[0]);
       og_set_group_context($group_node);
   }
   $type = $_GET['type'];
   if ($type) { <>   if ($type == 'forum') {
        if (user_access('create forum topics')) {
            $typeFound = 'yes';
            $output = node_add('forum');
        }
    }
etc...
 }
return $output;
}

This worked, but required that the user a) create a node, b) put this code in the node, c) rename the node to "addform", d) edit the og module to call "addform" instead of "node/add".

A lot to ask of a user, which is why I tried so mightily to figure out what the access problem was.

Someone on the development list once suggested using "hook_init". In seaching the Drupal site for ideas, I saw that someone had used hook_init to redirect url requests. So it hit me: Why not redirect node/add/type?gids[]=gid requests directly to my addform? But, instead of creating a separate node for addform, make it part of my module.

So, by using hook_menu to create the callback for "node/addform":

$access = $user->uid; // login is required
$items[] = array('path' => 'node/addform', 'type' => MENU_CALLBACK, 'callback' => 'og_user_roles_addform', 'access' => $access, 'title' => t('Create content'));

and, creating a re-direct in hook_init:

    // Looking for this format: http://www.mysite.com/node/add/link?gids[]=29 

    function og_user_roles_init ()
    {
    if (arg(0) == 'node' && arg(1) == 'add' && isset($_REQUEST['gids'])) {
    $gids = $_GET['gids'];
    $gid = intval(current($_REQUEST['gids']));

    $type = arg(2);

    $path = 'node/addform';
    $query = 'type=' . $type . '&gids[]=' . $gid;
    drupal_goto($path, $query);
    }
    }

I was finally able to get "node/add" working for og user roles without patching any core modules (user.module OR node.module).

If anyone is still reading this, I have one small development question:

Since my addform code is now basically replacing node_access in this circumstance, how do I check the "create" permission on any content type (not just "node" content type) for any module without having to know them all in advance?

Thanks for all the help. Again, I'll post notice of the update once completed.

Close. That code checks for all "node" content types, but not all content types. However, that code is called in node_access by a module_invoke that is created from the results of node_get_types(). So, I re-worked that code to give me this:

 //
// Got this from node.module (node_access)
// No matter the type, this should return us the create permission.
//
$module = node_get_types('module', $type);
if ($module == 'node') {
$module = 'node_content'; // Avoid function name collisions.
}
$access = module_invoke($module, 'access', 'create', $type);
if ($access === TRUE) {
$output = node_add($type);
}
}
return $output;

I've got this working. So, now all I have to do is re-work the code for some other changes, run some final tests, and we're good to go.

Thanks!

The latest OG User Roles distribution is now available here: http://ftp.scbbs.com/pub/drupal/og_user_roles/

Version: 5.x-2.x-dev

README.txt is attached.

Please test out and let me know if you find any problems.

Thanks!

Thank you webchick and bibo. I have implemented both the table prefix and secure code changes you both recommended. I will post notice with the updated module has been uploaded. I appreciate very much your assistance in pointing out these issues!

//    Line 652

    //              $result = db_query("SELECT uid FROM og_uid WHERE is_admin = 1 AND nid = " . $nid);
                  $result = db_query("SELECT uid FROM {og_uid} WHERE is_admin = 1 AND nid = %d", $nid); // FIXED TABLE PREFIX
     

//    LIne 913

    //          $query = 'SELECT role.rid, role.name FROM role INNER JOIN og_users_roles ON role.rid = og_users_roles.rid WHERE og_users_roles.uid = ' . $uid . ' AND og_users_roles.gid = ' . $gid;
    //          $results = db_query($query);
              $query = 'SELECT {role}.rid, {role}.name FROM {role} INNER JOIN {og_users_roles} ON {role}.rid = {og_users_roles}.rid WHERE {og_users_roles}.uid = %d AND {og_users_roles}.gid = %d'; // FIXED TABLE PREFIX
              $results = db_query($query, $uid, $gid);

//    Line 955

    //        $result = db_query("select node_access.gid from node_access INNER JOIN og_uid ON node_access.gid = og_uid.nid WHERE node_access.realm = 'og_subscriber' AND og_uid.uid = $uid AND (node_access.nid = $nodeID OR node_access.gid = $nodeID)"); // modified to check for either the node or group ID in node_access
            $result = db_query("select {node_access}.gid from {node_access} INNER JOIN {og_uid} ON {node_access}.gid = {og_uid}.nid WHERE {node_access}.realm = 'og_subscriber' AND {og_uid}.uid = %d AND ({node_access}.nid = %d OR {node_access}.gid = %d)", $uid, $nodeID, $nodeID); // FIXED TABLE PREFIX - modified to check for either the node or group ID in node_access

//    Line 965 

                if (user_table_exists('{og_term}')) {
    //                $result = db_query("select og_term.nid from og_term INNER JOIN og_uid ON og_term.nid = og_uid.nid WHERE og_term.tid = $nodeID AND og_uid.uid = $uid");
                    $result = db_query("select {og_term}.nid from {og_term} INNER JOIN {og_uid} ON {og_term}.nid = {og_uid}.nid WHERE {og_term}.tid = %d AND {og_uid}.uid = %d", $nodeID, $uid); // FIXED TABLE PREFIX 

 

New 5.x-2.x-dev distribution uploaded here: http://ftp.scbbs.com/pub/drupal/og_user_roles/

This has the changes discussed above, in addition to one major change: A "configure member roles" permission has been created. So, this permission must be given to any role allowed to use og user roles to give group members group roles. Before this change, you only had to be the group administrator to be able to assign group roles.

Thanks!

Finally got my own project for this:

http://drupal.org/project/og_user_roles

All future distributions can be downloaded from here.

Thanks to all of you who stuck with it.

And, special thanks to the OG Roles maintainer for letting me continue this thread until I got OG User Roles working.

Thanks for the note.

For me, the next step for OG User Roles is to get TAC and OG working together without core hacks. I've got them working now, with half the access control code in OG User Roles, and the other half (mostly db_rewrite_sql mods) in patches to node, taxonomy_access and og.

Details here: http://groups.drupal.org/node/3700

The group is called "Access Control" here: http://groups.drupal.org/access-control

Any help would be highly appreciated.

I'm not sure if you realize this or not, but what you just described, particularly with respect to this:

User Taxonomy Assignments:
U1 = GA, GA->R1, GB
U2 = GA, GA->R2, GB, GB->R1

So with this, the GA and GB term assignments can tell us that subterms are legitimate. User 1 belongs to both GA and GB. He also has the permission R1 for GA. User 2 also belongs to both GA and GB, but has R2 role in GA and R1 role in GB. Neither has site-wide (SW) use of these roles.

is precisely what OG User Roles does right now. It restricts "permissions" based upon the role(s) a user has within a group. And, this is without any taxonomy vocabulary.

Now, when we add taxonomy to the mix, we can further refine access based upon "term_access" (list/view/create/update/delete), or what I refer to as "grants".

As far as I can see, your cck show/hide field mechanism should have no problem in this environment.

The problem is with access control. Currently, if you create a group node, and assign to it a vocabulary term, a user will be able to see the node if he either a) belongs to the group or b) does not belong to the group, but has access to the term. This is insane.

What we want is for the user to only have access to the node if he has BOTH a) group access and b) term access.

Your cck scenario would work now, but you'd need to have some way to restrict the term access to just within the group, otherwise, non-group users who somehow have access to the vocabulary term would also be able to access the nodes.

That's what I've worked out here: http://groups.drupal.org/node/3700

What I haven't worked out is how to do it without hacking core/contribution modules.

I say all that to say that your idea still needs to address the TAC/OG issue if you intend to use taxonomy to make it work securely.

You might be able to get away with it using OG Vocab (I tried it and can't remember what the problems were), but it doesn't have near the richness of TAC. With TAC you can control not just who can see/not see a node, but you have total control of all "grant" operations.

My two cents.

OG User Roles doesn't use terms either.

That's a functionality I want to add so that I can have multiple layers of access within a single group. See attached.

In doing it this way, I'm trying to think of whether TAC would work along side, or get in the way. Let me see if I understand TAC. If a term is assigned (tagged) to a node, access is granted. This is regardless of whether access has already been denied by another module. Is this correct? Well, then, what if TAC were modified to check for both visible (tagged) terms and these cck-style taxonomy_fields terms, all in one module? It seems that TAC could easily collect permissions based on both the visible and invisible terms, AND them together and pop out a result.

If you look at the larger picture, it's not about what TAC does in particular, but Drupal Access Control in general. The way node_access works now, whatever your access control, it returns either a TRUE or FALSE or NULL. What we need is for the node_access to return TRUE if all access controls say (TRUE or NULL), or FALSE if just one returns FALSE. There's a very good discussion on this subject here: http://drupal.org/node/143075

Users should be unaware and not have access to this taxonomy. The taxonomy should be completely generated programmatically as groups and their nodes are added/updated/deleted/etc.

That's cool. But, in my scenario, I want to give users who have higher access the ability to decide who can and cannot see the content they post within the group. For that, you need to make the taxonomy visible, or have some selection mechanism the user can use which will select the correct vocabulary term(s).

Your idea sounds good, if it will work. Are you developing this module now? I'd certainly like to see what kind of progress you can make.