Views "access restriction" by role doesn't work with OGUR (even if OG context is correctly kept)

There are no "OGUR roles". OGUR dynamically and transparently grants additional, regular user roles depending on the group context of a page.

Again: Your users only have core roles. There is no such thing like a "ogur role".

OGUR dynamically grants additional core roles to users depending on the current group context. If you want to _list_ those role assignments using Views, then that's not possible (yet) and #729256: Views integration is what you want.

I'm still not sure what the actual issue/problem is. Can you post an - as simple as possible - procedure to replicate the issue you are facing?

subscribe

Views already contains such an access restriction "by role" feature (and even also "by permission"). Therefore, OGUR does not need to reinvent such an access plugin.

I'm not sure what's left to be done or not yet clear in this issue.

While i understand your frustration with the problem you are having I don't see any attached patches with your comments and they tend to come off as slightly ungrateful and entitled to help. Daniel has zero requirement to scratch your itch for you or even fix a bug in the module he helps maintain if he chooses not to do so for any reason he likes. A certain amount of frustration could be understood if you demonstrated an actual bug and provided a patch but withstanding that case I'm inclined to think this is your problem if you care to resolve it.

I need Views to know of OG user roles myself, so I did some "research":

OGUR has to be called before the Views' access plugin, so make sure OGUR has the weight '-1' in the system table. This seems to be included since version 6.x-4.0. Try the latest release and remember to run update.php (as I forgot at first)...

hum... did we forget a module update at some point to adjust the weight? It should be installed with -1 by default, but I'm not sure whether this is properly adjusted for older versions.

I feel your pain, I need a better OGUR/Views integration too, but frankly, given the time you obviously spent on the subject, you rather should've tried to hire a programmer for this. This is a free and open-source software, delivered as-is, and it won't help if you demand a solution for your problem once a week.

Speaking of which, I'll try to throw my programming student onto our own OGUR/Views problem...(which is aimed at better administrative filters for users with role x in group).

I have a solution for this. I needed OG User Roles access integration with views for a client, and there was no getting around it.

I wrote a views plugin that extends the normal views_plugin_access class. The name of my module is 'm29_organization', so you will have to take this into consideration. I have never written a patch, nor do I have much interest in learning how to do so at this time, so if someone else would like to submit a patch for OGUR, be my guest.

In m29_organization.module:

/**
 * Implement hook_views_api().
 */
function m29_organization_views_api() {
  return array(
    'api' => 2.0,
    'path' => drupal_get_path('module', 'm29_organization') . '/includes'
  );
}

/**
 * Access callback for use with m29_organization_ogur_plugin_access.
 *
 * Determine if the specified user has access to a view on the basis of any of
 * the requested OG user roles. If the $account argument is omitted, the current user
 * is used.
 */
function m29_organization_ogur_access($rids, $gid_arg, $account = NULL) {
  global $user;
  $account = isset($account) ? $account : $user;
  og_user_roles_grant_roles($account, node_load(arg($gid_arg)));

  $roles = array_keys($account->roles);
  $roles[] = $account->uid ? DRUPAL_AUTHENTICATED_RID : DRUPAL_ANONYMOUS_RID;

  return user_access('access all views', $account) || array_intersect(array_filter($rids), $roles);
}

in includes/m29_organization.views.inc:

/**
 * Implement hook_views_plugins().
 */
function m29_organization_views_plugins() {
  $path = drupal_get_path('module', 'm29_organization') .'/includes';
  return array(
    'access' => array(
      'ogur_plugin_access' => array(
        'title' => t('OGUR'),
        'help' => t('Will be available only to the following OG user roles.'),
        'handler' => 'm29_organization_ogur_plugin_access',
        'uses options' => TRUE,
        'path' => $path,
      ),
    ),
  );
}

In includes/m29_organization_ogur_plugin_access.inc:

/**
 * Access plugin that provides role-based access control.
 */
class m29_organization_ogur_plugin_access extends views_plugin_access {
  function access($account) {
    return m29_organization_ogur_access(array_filter($this->options['role']), $this->options['group_arg'], $account);
  }

  function get_access_callback() {
    return array('m29_organization_ogur_access', array(array_filter($this->options['role']), $this->options['group_arg']));
  }

  function summary_title() {
    $count = count($this->options['role']);
    if ($count < 1) {
      return t('No role(s) selected');
    }
    else if ($count > 1) {
      return t('Multiple roles');
    }
    else {
      $rids = views_ui_get_roles();
      $rid = array_shift($this->options['role']);
      return $rids[$rid];
    }
  }

  function option_defaults(&$options) {
    $options['role'] = array();
    $options['group_arg'] = '1';
  }

  function options_form(&$form, &$form_state) {
    $form['role'] = array(
      '#type' => 'checkboxes',
      '#title' => t('Role'),
      '#default_value' => $this->options['role'],
      '#options' => views_ui_get_roles(),
      '#description' => t('Only the checked roles will be able to access this display. Note that users with "access all views" can see any view, regardless of role.'),
    );
    
    $form['group_arg'] = array(
      '#type' => 'textfield',
      '#title' => t('Group Argument'),
      '#default_value' => $this->options['group_arg'],
      '#description' => t('Define which path argument is the group nid.'),
    );
  }

  function options_validate(&$form, &$form_state) {
    if (!array_filter($form_state['values']['access_options']['role'])) {
      form_error($form['role'], t('You must select at least one role if type is "by role"'));
    }
    
    if (empty($form_state['values']['access_options']['group_arg'])) {
      form_error($form['group_arg'], t('You must specify a valid path argument.'));
    }
  }

  function options_submit(&$form, &$form_state) {
    // I hate checkboxes.
    $form_state['values']['access_options']['role'] = array_filter($form_state['values']['access_options']['role']);
    $form_state['values']['access_options']['group_arg'] = $form_state['values']['access_options']['group_arg'];
  }
}

Basically to sum everything up, this duplicates the basic role access plugin provided by views, adds a form element to specify which path argument is used as the group id, and calls a custom handler that integrates with OGUR.

The group context does not need to be set anywhere else for this to work. I saw numerous postings regarding setting the group context in the views header, but this is terrible practice. If you need the group context for something other than access, it should not be done in the views header (someone unrelated, but feel it is important to mention it here).

A couple additional notes:

• In my access callback, I call node_load. If someone has a suggestion on how to improve this for best practice, that would be great.
• My access callback also calls arg(). If someone would like to improve on this to actually pull in the argument from the context of the view (in the plugin), that would be great.

Hope this helps everyone!

That would translate into this OGUR patch for me. By all means, I'm no expert in this area. No idea how to make it use a proper Views/Panels context. But if this happens to work, I'm happy to move forward with this already and commit it.

Also, @j.helmer, you should totally learn how to do patches for Drupal! :) http://drupal.org/patch will help you. Everyone in IRC #drupal on irc.freenode.net will certainly too!

@sun -

thanks for the pointer. I will definitely learn how to do patches as I get more involved in the drupal community, though I develop for drupal professionally, so I would have to learn it on my own time or when we are not busy and there is time for drupal research.

@j.helmer: Many (if not even most) people in the Drupal community are doing exactly what you are doing, and they learned it on purpose -- consider that you don't need to apply any hack or workaround next time you need a functionality, and, that you can freely update to newer versions at any time.

Sorry for this off-topic interlude. :)

@sun - Thank you for your input. I look forward to contributing more to the Drupal community.

@MXT - Just use role-based access as you normally would. It just "works."

I attached a screen shot in case my previous explanation lacked.

@sun - Not sure how this works, but should we change the status of this issue to "Patch" so we can get it ported into the next stable release?

@MXT - I spoke too soon. This morning, I removed the code from my module and tried applying the patch sun made. It didn't work. Looking through the code, I found a few problems:

• My code points to an includes/ directory, so og_user_roles.views.inc and og_user_roles_plugin_access_role.inc should lie in a subdirectory called includes.
• The plugin should use its own namespace (I just switched it to ogur_role), but sun changed it to 'role'.. this can cause a lot of bad things to happen:

Note that unlike handler registration, where parentage is referred to by object name, with plugins it is referred to by the unique plugin identifier. Please be sure to prefix your plugin identifiers with your module name to ensure namespace safety; after all, two different modules could try to implement the 'grid2' plugin, and that would cause one plugin to completely fail.

                                                                                                                                                                                                                                                                ~merlinofchaos

• For some reason, even after all those changes are made, views is not happy. When trying to choose the access role, views AJAX complains: "Class views_plugin_access_role not found"
• It works when extending views_plugin_access as I had originally done, except that sun has modified the code to rely on the parent plugin, so we need it to work with views_plugin_access_role.

@sun - Any input here? To start out, the patch should drop those .inc files into an includes/ directory. Next, we need to figure out how to properly extend views_plugin_access_role.

Does anyone else have any pointers about how to accomplish this? I created a new forum topic about it: http://drupal.org/node/873710

Sounds like a bug in Views' plugin autoloading.

Not quite there:

• The actual access doesn't work. I am not sure what access callback is being run, but I'm not getting any devel output from function access() at all.
• Maybe get_access_callback is necessary? It was working perfectly before your improvements, and I had that defined.
• hook_views_api() no longer points to /includes, but hook_views_plugin() does. The patch should probably force the views.inc and plugin include to reside in an includes directory (from http://drupal.org/patch/create):

Adding directories

It is also possible to use cvs patches to add a directory. For example, to add an add-on module to an existing module.

1. Within a directory that cvs knows about, add a new file to cvs shown above. With contributed modules, this would be in the root directory of that module.
2. Create the patch file by modifying CVS/Entries and using the -N switch shown above.
3. Edit the patch file adding the directory path that the files should reside in.
4. Example shown below, the first part shows the first few lines of the patch file created in the module root, after editing, I manually add 'contrib/exhibit_apachesolr' in front of any reference to the new file.
5. After running the patch file, on a cvs checked out module, it creates both the file exhibit_apachesolr.info inside the created directory exhibit_apachesolr (that resides under contrib).

Index: exhibit_apachesolr.info
==============================================================
RCS file: exhibit_apachesolr.info
diff -N exhibit_apachesolr.info
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ exhibit_apachesolr.info 8 Nov 2008 16:18:41 -0000

Index: contrib/exhibit_apachesolr/exhibit_apachesolr.info
==============================================================
RCS file: contrib/exhibit_apachesolr/exhibit_apachesolr.info
diff -N contrib/exhibit_apachesolr/exhibit_apachesolr.info
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ contrib/exhibit_apachesolr/exhibit_apachesolr.info 8 Nov 2008 16:18:41 -0000

Note that I have no use-case for this feature/patch myself, just trying to get you guys getting along.

The actual access doesn't work. I am not sure what access callback is being run, but I'm not getting any devel output from function access() at all.

I would have tested it, but I'm not sure how to use this access plugin, effectively.

Maybe get_access_callback is necessary? It was working perfectly before your improvements, and I had that defined.

Can you try? I've seen you had that in your code, but upon looking up what Views actually does in that logic/code, it didn't look like it would be necessary.

hook_views_api() no longer points to /includes, but hook_views_plugin() does.

Ok, looks like my preference breaks some expected standard file layout. ;) Fixed. Shouldn't have an impact on the functionality though.

However, s/includes/views/. Views is not the only API that allows other modules implement plugins.

Hope this helps.

Hey MXT,
I can feel your pain - being not a programmer, I had to give up on a project to build a drupal site because I couldn't get the permissions system to work properly (didn't hurt as much, though, since it was just for my own needs). The problem was probably the same as you suffer from:
- on a group node (e.g. ?q=node/61), the OGUR permissions are clearly there, as the the group detail block shows (see group-node.jpg)
- navigating to a viewtab on the node (e.g ?q=node/61/documents), the group context is still there (otherwise the detail block wouldn't display), but the OGUR permissions are clearly missing (see group-node-view-tab.jpg).
If money can fix this (hiring a programmer) I might throw in some of my meager resources.

subscribing

Hey, guys. Sorry I haven't been available for a while.

@MXT: in response to the following:
@j.helmer, I have a question for you: under "access options" form, where OGUR roles are listed to choose from, there is a "Group Argument: Define which path argument is the group nid." input form. What is this supposed to do? How it works? I have no arguments in my path and no views arguments defined: I retrieve group context using "Organic groups: Group node (post)" RELATIONSHIP and filter Views results with "(Group) Organic groups: Group member" filter (so a user can view only his group items).
What can I do in this case? any suggestion?

I built the access plugin for a particular case, where the argument is available in the url. My only suggestion (other than writing a new plugin, or re-writing this one) is to change up the way your view works to grab an argument from the url (if possible). Sorry; I don't have the resources right now to develop this more.

@khad: Be sure to set the ACCESS RESTRICTION on the /documents view to OGUR and select "1" as the OGUR context argument. You should be good to go, assuming MXT's patch works (I never tried his revised version of my code).

I'm not a views guru, but I needed this function in views3. I've made it - I think - compatible with views2, based on patch #33.
I've just downloaded the http://drupal.org/project/og_views_extra, and merge some useful thing.

The goal was the next: I wan't use an independent callback function, when ogur settings active in views.

I've changed the numbering of argument, if it's zero, there aren't argument validation, just use a default group context.

In plugin I don't use anything from parent in access and get_acces_plugin functions, just set callback to

  function get_access_callback() {
    return array('og_user_roles_view_access', array(array_filter($this->options['role']), $this->options['arg_group']));
  }

And the access callback:

/**
 * User role views access helper function.
 *
 * @return Has the current user access on current view.
 */
function og_user_roles_view_access($rids, $arg) {
  global $user;

  if ($arg == 0) {
    $group = og_get_group_context();
  }
  else {
    $group = node_load(arg($arg-1));
  }

  //Now we can use the normal arg() mapping in views settings page??
  if ($user_roles = og_user_roles_grant_roles($user, $group)) {
    foreach($rids as $rid) {
      if (array_key_exists($rid, $user_roles)) {
        return TRUE;
      }
    }
  }
}

Hmm.. The previous doesn't respect 'access all views' role..

... n/m

I'm debugging the same issue on one of my sites. I haven't tried the patches in this thread, and I'm pretty skeptical whether they are taking the right approach.

As far as I can tell, there are two problems. Again, this is without applying patches, and using the regular views access by role.

First problem, the main problem here, is Drupal's menu code is calling views_access() before OGUR has a chance to add roles. I'm not sure if there's going to be any easy way to get OGUR to act first.

Second problem, is og_user_roles_grant_roles() fails to learn the group context. It has fancy-pants code that inspects the menu items. But that slick stuff works on menu paths like node/%menu/edit, but not node/%/members (i.e., the kind of menu path that views adds - note the %node versus just plain %). See #940462: OGUR permissions lost while in OG context for a possible fix for this problem.

Update with a correction... the first problem is not that drupal's menu is calling access hooks too soon. Rather, it is og_user_roles_init that is causing the access hooks to be called.

There's a comment above og_user_roles_determine_context() which clearly states this is undesirable:

 * The only difference to the original og_determine_context() is that we are
 * intentionally using our own menu system functions, so we can determine
 * the group context without setting access for the current menu path (which
 * is statically cached in menu_get_item()).
 *

... despite the comment, og_user_roles_menu_translate() later calls _menu_load_objects(), which I think because of i18.module causes menu to call the access hooks and cache results. It's a long convoluted stack trace. I think this problem only occurs when i18n.module enabled. I also think I've encountered it before and worked around it with a custom hook_init(). I need to search for that thread...

Ok, hopefully the last time I have to correct myself in this thread.

It's not becasuse og_user_roles calls _menu_load_objects. Rather, it's all baked into i18n.module. Anything that calls node_load() will cause i18n to cause drupal to call the access hooks.

I put a terrible hack into my custom module's hook_init to work around this. Feel free to use it. You'll need to change my test for node type 'group' to whatever is appropriate for your site. And you'll need to adjust your custom module's weight to come before og_user_roles or any module that might call node_load in hook_init.

/**
 * Implements hook_init().
 *
 */
function CUSTOM_init() {
  // For complex reasons, when i18n enabled, we need to do this BEFORE og_user_roles_init() is called.
  if (arg(0) == 'node' && is_numeric(arg(1))) {
    i18n_selection_mode('off'); // i18n will screw up og_user_roles.
    $node = node_load(arg(1));
    i18n_selection_mode('reset'); // return i18n to it's original mode.
    node_load(0, 0, TRUE); // reset node_load cache

    if ($node && $node->type == 'group') { // Is there a better test for group?
      global $user;
      og_user_roles_grant_roles($user, $node);
    }
  }
}

I don't know whether it makes sense to put something directly into og_user_roles, for those cases when i18n is enabled. All you'd have to do is i18n_selection_mode('off') at the start of og_user_roles_init(), and reset that mode, and the node_load cache at the end. I leave that up to you.

@Dave Cohen: Thanks for the analysis. So after all the debugging, it looks like your issue is actually a separate one and not related to this here about Views? If so, we might want to create a separate for i18n compatibility/integration? (and link to it from here)

scribe

I believe that the cause of this issue is related to how the module, and og, determine the group context: og_user_roles_determine_context(), and og_determine_context().

Essentially both modules, group context calculation depends on the path of the request, and that it must contains the information needed to determine the OG, either a nodeID or the the query parameter: gids . But in the case of a views page, it is not included, resulting in that the group value will be NULL, see both: og_determine_context(), and og_user_roles_determine_context(), and then og_user_roles_grant_roles() will not assign the proper roles to the user.

This situation may happen on any defined path in the site that does not contain the OG information, such as AJAX callbacks (filefield, realname_userreference), views, hook_menu implementations, etc.
In my case, the issue was that when a user was editing a node, they would get a filefield access denied popup. The site uses Content Permissions.

To solve this I had to add in my implementation of hook_init, this code:

  // Only if it is not possible to determine the og context
  if (!($og = og_get_group_context())) {
    //the path may be a view with a URL pattern as: node/%/edit/extra-operations-etc
    if (arg(0) == 'node' && is_numeric(arg(1))) {
      $current_node = node_load(arg(1));
      $og = og_determine_context_get_group($current_node);
      og_set_group_context($og);
      $_SESSION['gid'] = $og->nid;
    }
    else {
      if (isset($_SESSION['gid']) && is_numeric($_SESSION['gid'])) {
        $og = node_load($_SESSION['gid']);
        og_set_group_context($og);
      }
    }
  }

This is assuming that the user already have access to edit the node. Also I needed to reset the custom module weight to be lighter then og and og_user_roles.
You may include other conditions particular to your case.
Also adding ?gids[]=### to the URL should fix this issue without any programming.

I know is not specifically for your case, but I hope it helps.