Are member-level (NOT Role-level) permissions possible within an OG?
work77 - September 21, 2009 - 22:59
Is it possible to give a member of an Organic Group (e.g., manager, admin, anyone...) the authority to limit who in that group can see what? This has to be more granular than the functionality found in OG User Roles. Basically it would be a user-based ACL solely for a group.
I'm using OG because it's the only way I've found to create an infinite number of groups of users. But now the challenge is controlling access to particular individual nodes of a content type to particular group members. I've been struggling with this for weeks. If you know of a better way, please share.
If this should be in another forum, my apologies. Please let me know which one.
Thanks.
_
You might be able to do this with http://drupal.org/project/nodeaccess_userreference using a view that displays all the members of the group for the values of the user reference field.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
uhg
To give you an idea of where I'm at in my Drupal education, I just learned how to create views to generate sql. After wrestling with the nodeaccess_userreference module for two days, I've made little progress accomplishing the above task. Truthfully I'm not clear on exactly what the nodeaccess_userreference even does. I've created a field of type User Reference and added it to my Group Post Content type. When I go to edit a node of that Content Type, I thought magically, a member list of that current group would appear where I, as the admin of that group, could simply check which members can/cannot see that particular node. But no such luck. There is no change on the edit page.
As per the description in, http://drupal.org/project/nodeaccess_userreference ...
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This module allows you to configure a CCK user reference field so that the user whom is referenced in a node is granted access to view the node. There are also options to give the user access to edit or delete the node.
>>I don't know what "user whom is referenced in a node", with regard to my situation, means.
This is great if you want your node authors to be able to choose additional authors,
>> Will this functionality be available only to node authors? Ideally a group admin could control who can see what in that group, regardless of whether she authored it.
Please note that this module will remove the default view access people have on a node - you will need to use a different Node Access module to grant default access to users. I recommend doing it by taxonomy, or per node.
>> For my purposed, I really don't understand how "need to use a different Node Access module" applies. I've read multiple access modules causes trouble. I've already had to remove Content Access because all non-group members were able to access member-only content.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
I'm feeling really scatter-brained now. Any direction would be awesome.
_
Don't sweat it-- we've all been new at one time or another.
OK, the nodeaccess_userreference field enables you to allow node authors to list which users should be able to access a node. So, given a node belongs to a group, na_ur might enable you to further restrict the node.
First, you don't want to put the userreference field on the group content type-- you put it on the content types that can be group nodes.
Second, you'll have to create a view of users belonging to groups, with an argument for the group, to use as the source for the userreference field if you want to limit the list of users to members of the group.
does that help?
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
#
"First, you don't want to put the userreference field on the group content type-- you put it on the content types that can be group nodes."
>>>So just to clarify, I should put it on my Group Node Content Type, NOT the Group Post Content Type?
"Second, you'll have to create a view of users belonging to groups, with an argument for the group, to use as the source for the userreference field if you want to limit the list of users to members of the group."
>>>I believe I can create the View with the group argument. But I'm not seeing how to officially connect that View to be the source of the userreference field. When creating the field I don't see anything resembling a "source" option. I only see Label, Field name, HelpType of data to store, Form element to edit the data.
Just an overview of what I'm up to: I only want to create the content once. So first, I'm creating "Group Post" content. Then under Audience I check every group name (but not the Public box). The dream is to then have an admin (or someone) from each group be able to pick and choose who from that respective group can/can't see that content. I'm not sure if this is the correct route but if there's a better way, I'd be interested in a suggestion.
Thanks again.
_
1) LOL, ok let me try again. Don't put the userreference field on the content used to create groups, put it on the content types that will be posted into groups.
2) don't you have a "Advanced - Users that can be referenced (View)" option on the user reference field?
3) I think this will give you want you're looking for.
EDIT:
It seems that og already provides view that could be used for #2: og_members.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
#
Okay. After applying a few patches and setting the permissions to view/edit/delete that new UserRef field, I can now at least see my new "User Reference" label when editing a Group Post. Unfortunately, this introduces more issues I'm struggling to figure out. The view doesn't display any of the group members. So, for kicks I hardcoded a Group ID in the Arguments field when editing my userRef field. Saved that, then I could see some users. But obviously this is no solution. Am I right to think there should be SOMETHING put into that Arguments field, though? '\1' didn't work either. I don't know how to associate the argument that the View needs with the correct Group Node ID (that that Group Post is associated with). If I'm supposed to be grabbing it from the URL, then that's a problem because the only variable there represents the Group POST id, not the actual Group Node id. Is there some magical global variables array that I have access to that would includes the current Group Node ID?
Hope I'm not coming across as a Help Vampire. I'm really trying/researching everything before I post. :)
Thanks again.
_
not vampy at all-- so no worries. ;-)
I forgot about the argument thing-- you'll probably want to clone the view first (so you still have the original), then you'll need to add an argument for group id and use the 'provide default argument' option. I don't know the exact config off the top of my head, but I'll check it out when I get a chance and post back.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
_
Ok I see now how the 'provide default argument' will grab a Node id from the URL. Cool. Now the issue is that the Group Post Node (not the Group Node) is the only arg in the URL. I need to somehow find the associated Group Node. The only link between a Group Post Node and the Group Node, into which the post was made, is the node_access table. But it looks like I cannot create a view (sql) that involves the node_access table. Am I seeing it correctly that Views allows you to use only a FEW pre-selected tables? I don't understand this limitation. It would seem that, as the admin, I should be able to create a view with ANY column from ANY table in the database.
Thanks again.
_
Try this in the php code option of the provide default argument setting:
if ($node = og_get_group_context()) {return $node->nid;
}
else {
return NULL;
}
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
_
Oh-- and yes, views only has access to those entities that have been described to it. Many modules provide views support by default, but you can also provide your own access or access to any table in the db, you just need to define the table with hook_views_data. See the advanced help provided with views for more info. It's actually pretty simple to do.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
_
Thanks for the help WorldFalls. Not that I've finally gotten it usable, unfortunately I'm still not able to do what I am after. I've started a new thread here http://drupal.org/node/593398 to focus on just the Node Access User Reference module and it's behavior with OG.
thanks again.
_
ok now i'm on a mission, lol. I just put up a dev site and I can confirm na_ur does exactly what you need. It works! I just need to figure out the correct code for the 'provide default argument' code to only list the users from the current user's group. Right now I have it setup to show all users just to confirm the setup will work.
One other question-- can a user be a member of more than one group? If so, do you want the members listed from all groups to which a user belongs?
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
quick response
Hey. Welcome aboard! Just to give you a quick response....this is the code I threw together to grab the users in the Group with just the Post ID. Of course, this will break if node_access rows are being removed as I mentioned above. This is not the ideal for many reasons, but just to test with. I have no idea if I'm doing things correctly though. The commented out area is just for debugging. I'm going to process your response more thoroughly when I get a chance. thanks much.
function danGetGroupFromPost() {
$args = arg();
$res = db_fetch_object(db_query("SELECT gid
FROM {node_access}
WHERE nid='%d'
LIMIT 1 ", $args[1]));
if(isset($res->data)) {
$res->data = db_decode_blob($res->data);
if($res->serialized) {
$res->data = unserialize($res->data);
}
}
/*
$fh = fopen('hits', 'a+');
// $vard = serialize($args);
$vard2 = serialize($res);
fwrite($fh, " fh is $fh and args[1] is |".$args[1]."| and res is $vard2 \n_________\n");
fclose($fh);
*/
return $res->gid;
}
return(danGetGroupFromPost());
"can a user be a member of
"can a user be a member of more than one group? If so, do you want the members listed from all groups to which a user belongs?"
For our purposes we'll say no. A user can only belong to one group. No, I only want the members who belong to the group that the Post is posted into, and that the "Editing" admin is in, to be on the list. In the event that the Post is posted to more than one group, the admin, could change that Post's visibility within HER group ONLY.
_
That's makes it a WHOLE lot easier, here's the view you should use for the nodeaccess_userreference field:
$view = new view;$view->name = 'og_members_ur';
$view->description = 'Member listing';
$view->tag = 'og';
$view->view_php = '';
$view->base_table = 'users';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('fields', array(
'name' => array(
'label' => '',
'alter' => array(
'alter_text' => 0,
'text' => '',
'make_link' => 0,
'path' => '',
'link_class' => '',
'alt' => '',
'prefix' => '',
'suffix' => '',
'target' => '',
'help' => '',
'trim' => 0,
'max_length' => '',
'word_boundary' => 1,
'ellipsis' => 1,
'strip_tags' => 0,
'html' => 0,
),
'empty' => '',
'hide_empty' => 0,
'empty_zero' => 0,
'link_to_user' => 0,
'overwrite_anonymous' => 0,
'anonymous_text' => '',
'exclude' => 0,
'id' => 'name',
'table' => 'users',
'field' => 'name',
'relationship' => 'none',
),
));
$handler->override_option('sorts', array(
'name' => array(
'id' => 'name',
'table' => 'users',
'field' => 'name',
'order' => 'ASC',
'relationship' => 'none',
),
));
$handler->override_option('arguments', array(
'nid' => array(
'default_action' => 'default',
'style_plugin' => 'default_summary',
'style_options' => array(
'count' => TRUE,
'override' => FALSE,
'items_per_page' => 25,
),
'wildcard' => 'all',
'wildcard_substitution' => 'All',
'title' => 'Members of %1',
'breadcrumb' => '',
'default_argument_type' => 'php',
'default_argument' => '',
'validate_type' => 'og_group_types',
'validate_fail' => 'not found',
'break_phrase' => 0,
'not' => 0,
'id' => 'nid',
'table' => 'og_uid',
'field' => 'nid',
'add_table' => 0,
'relationship' => 'none',
'default_argument_fixed' => '',
'default_argument_php' => 'global $user;
return array_shift(array_keys($user->og_groups));',
'validate_argument_node_type' => array(
'forum' => 0,
'attachments' => 0,
'gallery' => 0,
'group' => 0,
'image' => 0,
'multi_image' => 0,
'og_private' => 0,
'page' => 0,
'profile' => 0,
'profile2' => 0,
'story' => 0,
'testing' => 0,
'user_ref_test' => 0,
),
'validate_argument_php' => '',
'require_value' => 0,
'reduce_duplicates' => 0,
'default_argument_user' => 0,
'validate_argument_node_access' => 0,
'validate_argument_nid_type' => 'nid',
'validate_argument_vocabulary' => array(
'1' => 0,
),
'validate_argument_type' => 'tid',
'validate_argument_is_member' => 1,
'validate_user_argument_type' => 'uid',
'validate_user_roles' => array(
'2' => 0,
'6' => 0,
'3' => 0,
'4' => 0,
),
'default_options_div_prefix' => '',
'validate_argument_transform' => 0,
'validate_user_restrict_roles' => 0,
),
));
$handler->override_option('filters', array(
'status' => array(
'id' => 'status',
'table' => 'users',
'field' => 'status',
'operator' => '=',
'value' => 1,
'group' => 0,
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'relationship' => 'none',
'expose_button' => array(
'button' => 'Expose',
),
),
));
$handler->override_option('access', array(
'type' => 'none',
));
$handler->override_option('cache', array(
'type' => 'none',
));
$handler->override_option('empty_format', '1');
$handler->override_option('items_per_page', 0);
$handler->override_option('use_pager', '0');
$handler->override_option('distinct', 0);
I've got it working now-- it's actually pretty slick-- I may end up using it myself! Give it a try and let me know.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Thanks for going through the
Thanks for going through the trouble, WF. That part definitely looks cleaner than my code :) . Sadly, this doesn't eliminate the overall issue (http://drupal.org/node/593398), and unreferenced group members are still able to see the node. I don't know what else to troubleshoot. The node is for group members only, the audience is checked for just that group and is not public. I have disabled and uninstalled ALL other user access modules to prevent potential conflict. There are no overriding Roles that have been assigned to the users. Only the 'access content' permission has been checked, and if I unchecked that no one would see anything ever.
Does your test involve a Group Post Node and Group members? I'm using Drupal 6.13. Not sure if 6.14 would make a difference.
Thanks.
_
hmmm... something is definitely wrong there. Yes, I set up 2 groups, and tested all scenarios both within the group, within the other group, and with users belonging to no groups at all. Every thing functioned as expected. I know that installing and removing nodeaccess modules can create a huge mess. Maybe try setting up a fresh site and install only og, cck, and nodeaccess_userreference. Then create some test users and nodes and try again.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
ugh
uhg. Setting up from scratch at this point would really hurt my feelings :) but, yes, it may be necessary.
A couple quick questions.
1) Do you have "Organic groups access control" enabled in your modules? I do.
2) You referenced the "$user" object in your code. Knowing that object exists would have saved me some time. Is there a list somewhere of the objects available to coders?
_
1- yep.
2- yeah, somewhere or other in the handbooks, lol. But since modules and themes can add all sorts of things it's easier to just do something like
<?php print '<pre>' ; var_dump ( get_defined_vars ()); print '</pre>';or, if you use devel,dsm(get_defined_vars ());(much more user friendly display using krumo)._
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Here we go...
I'm starting from scratch and have installed 6.14. I want to make sure I'm doing things right from the beginning. I didn't have Updates activated before. When enabling OG, Updates is recommending I install the more current Dev version, and NOT the "Recommended Version" that I would normally install. Which do you suggest? Is it a good habit to follow the Update's suggestions usually/always? Thanks again.
Organic groups 6.x-2.x-dev (2009-Sep-22)
Recommended version: 6.x-2.0 (2009-Aug-18)
* Download
* Release notes
Development version: 6.x-2.x-dev (2009-Sep-25)
* Download
* Release notes
Includes: Organic groups, Organic groups Views integration, Organic groups access control, Organic groups actions
_
Ah--- good idea. I've got d6.14, og 6.x-2.x-dev (9-26), cck 6.x-1.x-dev (9-29), nodeaccess_userreference 6.x-2.5, and views 6.x-2.x-dev (9-29).
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Thanks. Glad I asked. I see
Thanks. Glad I asked. I see you're using the most recent dev versions of CCK and Views too. So, for future module installations, how do I know when to use the most recent dev versions and when those are too risky and should opt for the "recommended version". Is there something I can refer too?
And I think you mean cck 6.x-2.x-dev, correct? I didn't see the one you listed here, http://drupal.org/project/cck
_
There's no easy answer for that-- I tend to use the dev versions of the major modules because I trust they're either stable or will have a note on the project page warning when they're not. You'll get a feel for it after a while. And obviously, if you're having problems with something, it's always good to try the devs. But always test before upgrading a production site.
As for cck-- it was a typo. I'm using http://drupal.org/node/266142 (6.x-2.x-dev).
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
bad news
I created a whole new web site from scratch and got the very same outcome. Group members who were not selected in the User Reference field can still see the content. It's interesting that when I edit that Post node, my user checkbox selections HAVE been preserved (Checked users remained checked. Unchecked users remain unchecked). But it's like there's something overriding those User Reference settings. The Posts are correctly NOT visible outside of the group. So, I'm thinking it's not an issue with Roles or permissions...
Not sure where to go from here. I feel desperation setting in. I'm using postgres. Are you using mysql?
Thanks tons for working with me, but I seem to be cursed for this mission.
_
ahhh... I dont' think I understood exactly what you were trying to do. Any post in a private group will be viewable to all members of the group-- by default. I was adding edit/delete permissions and letting non-group users have access to the private groups post. 'private' in the context of og is relative to that group, not within the group.
What we need is some way to make the group post private first, and then add users via the userreference field. what about adding the http://drupal.org/project/private module to set the node private?
EDIT:
Tried it, doesn't work either. I did some more research and found: http://drupal.org/node/270000. Based on bullet #5, I'm not sure how you can do this. Maybe the http://drupal.org/project/module_grants module can help. Maybe ask in irc?
EDIT2:
I should clarify-- it doesn't work as long as the post belongs to a group. If you don't need the post to belong to a group, just have the nodeaccess_userreference field list members of the group, then it works fine. Make the node private and grant users access via the userreference field. It works as expected. The problem is, once the post belongs to a group, og 'grants' access and no other module can 'ungrant' it.
does that make sense?
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
still truckin
Hey WF. I had tried the Private Module before as well, and you are correct that it does not work. I'll take a look at the Module Grants mod you mention, but I may have come up with a different approach (if it's feasible). I was manually playing around with the node_access table and discovered that, to accomplish what I'm after, only a few actions need to take place...
1) When a new Group is created, the record with og_subscriber in the realm field is added into node_access. This Insert needs to be modified so ALL grants are set to 0. Then, by default, NO group members could view content.
2) I noticed that when editing the Group Post node, the checkbox selections are determined by the content_field_user_ref table. Upon form edit
submission, all rows in that table are being deleted, then the new rows (for each checked user) are Inserted for that node. Unfortunately, this submission action also resets the same View grant that we took away in node_access described in the step above. SO THAT BEHAVIOR HAS TO BE REMOVED!!
That's all :) Now me being a complete Drupal newb, can you suggest the best way to make these small adjustments? Should I make a module from scratch? Can I make a module that alters the behavior of other modules (og, node_userref, etc. )? I'm not proud to say I've only accomplished a hello_world module so far. I suppose I could just use brute force and alter these queries as they are currently written. But what is the "proper" route to take?
Thanks.
_
Sorry, no clue-- I'm not that intimately familiar with the og api-- maybe post to the issue queue or ask in irc?
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Coming late to the game here, but...
It's possible that with two methods of controlling access to the same node, one is cancelling the other.
RE: group members being able to see the node even if they are not assigned to it, is it possible that this is because this is the default behavior of OG?
And please feel free to disregard this if this is off-topic/not relevant --
Cheers,
Bill
-------
http://www.funnymonkey.com
Click. Connect. Learn.
Using Drupal in Education
-
Not off-topic. Thanks. When a new Group is created, the record with og_subscriber in the realm field is added into node_access. The trick is manually tweaking that behavior to NOT insert that row. Then by default no group members can see any of that group's posts. Member access to a node can subsequently be added/removed via nodeaccess_userreference. Now I'm just trying to create a new module that will allow a group's admin to assign/unassign particular nodes to particular members all from one page. If you're interested, my current struggle is just how to create this simple form ( http://drupal.org/node/615424 )
Thanks