It looks to me as if the additional permissions are only assigned if:
- the URL ends in the group node (e.g. ?q=og/users/61 or ?q=node/add/document&gids[]=61)
- the URL ends in a node that is a group post.
The permissions get lost when you navigate to a viewtab on the group node (e.g ?q=node/61/documents) or visit the group forums (e.g. ?q=node/61/og/forum/200), although the group context is kept in those cases (the group detail block displays).

I initially posted this as http://drupal.org/node/737292#comment-3476410 since I thought it was related (this post had two images attached to show the problem graphically), and http://drupal.org/node/923632 seems also to be a symptom of this. I tried to compare the functions OGUR uses to establish the group context to the original ones used by OG, but I could not understand the code enough to see what makes the difference...

CommentFileSizeAuthor
#7 og_user_roles_context.diff497 bytesDave Cohen
#4 ogur.patch870 bytesszantog

Comments

khad’s picture

Well, I do not really understand what I'm doing, but:
looking at the code, I guessed that the problem may lie in og_user_roles_determine_context() not being able to get a node object. I therefore put

if (empty($node)){
$node = node_load(arg(1));
}

right before the final line that does the checking:

 if (!empty($node) && ($group_node = og_determine_context_get_group($node))) {
    return $group_node;
  }

and this seems to eliminate the problem for me. Hope it doesn't open Pandora's box...

khad’s picture

Status: Active » Needs review

Even simpler:
replacing the initial call:
$object = og_user_roles_menu_get_object();
by:
$object = node_load(arg(1));
seems to work as well.
I'm setting this to 'needs review' so hopefully people less ignorant than me are inclined to give their comments.

henrijs.seso’s picture

Status: Needs review » Active

Indeed this is a problem. I am building a site with panels and when I create a page with path node/%node/something, roles for that node are not assigned. Will take a look at module in a minute, but khads approach in #2 seems little off. probably og_user_roles_menu_get_object needs some patch.

In my case og_user_roles_determine_context fails. $item has full node object, but it is located here: $item['map'][1]->data, $item['map'][1] is actually ctools context.

So request would be to add some general check that would check if arg(0) is node and load node with arg(1) as nid and check if that node is group node with og_is_group_type() OR if maintainers consider ctools important enough, at least following check could be added...

  elseif ($item['map'][1]->type == 'node') {
		$node = $item['map'][1]->data;
  }
szantog’s picture

Status: Active » Needs review
StatusFileSize
new870 bytes

This is my solution. The group node checking doesn't need, because the $group_node = og_determine_context_get_group($node) makes it.

khad’s picture

Hmm,
#3 does not make any noticeable difference in my case,
#4 works on view tabs, but doesn't seem to work on group forum pages.
Sticking to my own 'solution' for the moment...
Now, I'm not expecting for anybody to teach me drupal, but - could you give me a clue why my approach isn't viable?
Does it fail under some circumstances, or are there other caveats?

newtoid’s picture

#2 worked for me in the situation i have, fortunately the argument is in the same place every time on all the different panels i am using. what a headache!

Dave Cohen’s picture

StatusFileSize
new497 bytes

I'm experiencing a similar problem. Here's a cleaner and safer patch to accomplish what's discussed here.

I find even with this patch, my site is broken. I'm using views to create tabs like node/%/members which lists the groups members. It seems that views_access() is called before OGUR has a chance to add roles to the user. So I'm still searching for a complete fix, but thought I'd post the patch anyway.

jvieille’s picture

Issue summary: View changes

The same kind of issue arises with node relationship.
I had to add this

 elseif (strpos($path, 'noderelationships/create') === 0 && !empty($_REQUEST['gids'])) {
    // URL pattern: noderelationships/create/event/field_lieu?gids[]=22
    $gid = intval(current($_REQUEST['gids']));
    $node = node_load($gid);
  }

Also, OG context is only available when creating/editing referenced nodes at parent node creation.
For NR to also work when editing a node, this fixes the issue:

in noderelationships.pages.inc, function _noderelationships_parent_node_form_alter

//...
    if (isset($noderef_settings['create_and_reference'][$field_name]) && isset($reference_fields[$field_name])) {
      // Compute the list of content types that can be referred from this
      // nodereference field and the current user is allowed to create.
      $field_creatable_types = array_intersect($creatable_types, $reference_fields[$field_name]);
      if (!empty($field_creatable_types)) {
        $field_settings[$field_name]['createUrl'] = url('noderelationships/create/'. $type_name .'/'. $field_name);
+// set context in edit mode 
+        if ($group = og_get_group_context()){
+          $field_settings[$field_name]['createUrl'] = url('noderelationships/create/'. $type_name .'/'. $field_name, array('query' => 'gids[]='.$group->nid ,'absolute' => TRUE));
+        }
      }
    }
    $field_settings[$field_name]['viewInNewWindow'] = !empty($noderef_settings['view_in_new_window'][$field_name]);
  }

  // If we're translating a node, then let's find missing translations for
//...