Integration with views - adding per-content type support

Thanks for the quick reply!

The module is reaaaly simple, it consists of 50 lines including comments:

/**
 * @file
 * Allow users to view all unpublished nodes, or unpublished nodes
 * of a specific type.
 */
 
/**
 * Implementation of hook_perm().
 *
 * Adds a global 'view all unpublished content' permission and also
 * a new permission for each content type.
 */
function view_unpublished_perm() {
  $perms = array('view all unpublished content');

  foreach (node_get_types() as $type => $name) {
    $perms[] = 'view unpublished ' . $type . ' content';
  }
 
  return $perms;
}

/**
 * Implementation of hook_menu_alter().
 *
 * Modifies the path node/nid to use our access callback.
 */
function view_unpublished_menu_alter(&$items) { 
  $items['node/%node']['access callback'] = '_view_unpublished_node_access';
  $items['node/%node']['access arguments'] = array(1);
}

/**
 * Returns true if the user has 'view all unpublished content' or if
 * they have the permission corresponding to the node's content type.
 */
function _view_unpublished_node_access($node) {
  // Only check permissions on nodes that are unpublished.
  if ($node->status == 0) {
    if (user_access('view all unpublished content')) {
      return TRUE;
    }

    if (user_access('view unpublished ' . $node->type . ' content')) {
      return TRUE;
    }
  }
  
  // If none of the above conditions were satisfied, then use node_access like normal.
  return node_access('view', $node);
}

The module works, I mean if a publisher with the permission "View all unpublished content" goes to see an unpublished node, he can view it fine. But views listing this node will remove it if the user is not 1 (using the published or admin filter). This wasn't the case before, so something must be causing this.

I have checked the filter published or admin code, and it hasn't changed at all since the first views version we started to build this site with, so I am really at a loss here, cant see what could be causing this or how to go about troubleshooting.

Oops Dereine, I think we were replying at the same time -- sorry!

OK, so humm... i remember our publishers being able to see these content before, ... X file?

I see waht you mean, although I am not familiar with this side of drupal code. I know there is an issue opened about this on the view_unpublished queue, #606516: View own unpublished content and respect module_grants - though I have tested it and unfortunately the problem did not go away. I am not knowledgeable enough to review the patch properly so I guess we are stuck for now until that gets worked on properly... and the module mantainer shows up :X

Thanks guys for the quick info, really appreciate it!

cross posted again sorry

Yes, this is correct merlin, thanks.

Dereine spent some time helping me doing just that last night, and we managed. I will clean it up and provide an initial patch for view_unpublished as soon as I can.

OK, the project is now live (you can check it out if you want at www.hobbynews.es), and is time to give back to the community, so we all prosper and conquer the world =)

Find attached the module that implements preliminary this integration. Keep in mind that we only use the "View all unpublished content" permission, so this is what we needed only. The module only takes over the query for view unpublished or admin filter, and takes into account this permission.

So there's not much to it, you just enable the module, and that permission will work with this filter automatically, nothing else to do.

It's a start, and I hope it will get in the module sometime. Feel free to discuss whether or not to put this as a separate module, and how to go about implementing this for the rest of permissions per content type.

BIG thanks to dereine for helping me get through the views maze without loosing my head too much, on a sunday night -> Big respect!

Just a heads up... my code has been used in production for hobbynews.es for nearly a year now. Working fine.

I haven't had time to test out the patch, but the code looks good to me, thanks hanoii!

Can anyone test it out properly please so we can set this to rtbc ?

Code makes sense to me.

Imho:

• #23 is ready to be committed to the 6.x-1.x branch.
• #30 is ready to be committed to the 7.x-1.x branch.