Configure Workbench Access by Content Type

No configuration yet (though it's in the plan). If you are comfortable with writing code, you can do this now:

From the api file:

/**
 * Allows modules to alter user privileges.
 *
 * Standard drupal_alter() hook to allow modules to modify the sections
 * that a user is allowed to edit. This hook is largely present to allow for
 * complex handling of content type permissions.
 *
 * @param &$access
 *   An array of access data, keyed by the access id. Passed by reference.
 * @param $account
 *   The active user account object. Note that this object may also be altered,
 *   since objects are implicitly passed by reference. Normally, you should not
 *   alter the $account object with this hook.
 */
function hook_workbench_access_user_alter(&$access, $account) {
  // Make content editing specific to assigned node types.
  if (empty($account->workbench_access)) {
    return;
  }
  $types = node_type_get_types();
  foreach ($access as $id => $data) {
    $access[$id]['update'] = array();
    foreach ($types as $type => $value) {
      if (user_access("edit any $type content", $account)) {
        $access[$id]['update'][] = $type;
      }
    }
  }
}

Currently, the permissions for a user pass the $id permissions as an array with one entry 'all'. You can alter this behavior using the above function.

    $access[$item->access_id] = array(
      'view' => array('all'),
      'create' => array('all'),
      'update' => array('all'),
      'delete' => array('all'),
      'preview' => array('all'),
      'revise' => array('all'),
      'publish' => array('all'),
    );

Then in the actual access check, we run this:

      if (in_array('all', $account_access[$id][$op]) || in_array($type, $account_access[$id][$op])) {
        return $id;
      }

So if you had a conditional statement, you could write something like so:

/**
 * Implements hook_workbench_access_user_alter().
 */
function custom_workbench_access_user_alter(&$access, $account) {
  // Make content editing specific to assigned node types.
  if (empty($account->workbench_access)) {
    return;
  }
  $types = node_type_get_types();
  foreach ($access as $id => $data) {
    $access[$id]['update'] = array();
    foreach ($types as $type => $value) {
      if (user_access("edit any $type content", $account)) {
        $access[$id]['update'][] = $type;
      }
    }
  }
}

This code, for instance, restricts editorial access according to the core 'edit any TYPE content' permission by section and should just work if you put it in a custom.module file.

If you aren't comfortable writing code, what I really need is a good UI pattern for setting these permissions. Should they go on the Permissions page? The Content Type configuration page? A custom Workbench Access settings page?

Ideas welcome.

A patch to the main module is perfectly fine, btw...

I'd really like some guidance from the UX team on this, actually.

would love to see this feature eventually implemented !!

+sub

Any ideas on how the UI should be formatted?

I agree with Simon Georges in #2. A simple use case would be excluding all Webforms from Workbench Access.

Having a single location to include/exclude a content type in the access tree like this would be ideal.

Personally, I really hate the "let's spread the configuration around to each content type config page" approach. I suppose we should do that and have a dashboard/overview screen that compiles all the settings as well.

Thanks agentrickard for the extensive documentation.

+1 to #8

Should this overview screen be a generic function, so other module's settings could use it as well?

Also, I like #2: "So, by starting with a settings on each content type page, unchecked by default, there would only be some clicks to have it working." This would mean enabling the module would not have the effect of immediately blocking all content editing access.

I am really looking forward to this feature. I like the idea of configuring this on the content type configuration page and agree with gaele.

Sub, I hope to be able to contribute some UI/UX work/recos here.

I think this one's pretty straightforward. It's #1155692: Allow per-section CRUD permissions that needs serious UI / UX design.

Pretty simple patch. Adds an option to the content type edit form and to Workbench Access configuration.

Any thoughts about the use of the fieldset? Should it not be collapsed?

Screenshots of the form elements.

Revised to use 'enforce' consistently on the UI.

Now with a shiny new test.

After I applied this patch I unchecked the article content type. I then went to node/add/article and the Workbench Access select list appeared in the form. I don't think that's the intended behavior.

Also existing nodes article nodes reported in the WB message block the sections to which they had previously been assigned. While I do not think nodes should be removed from their sections on a database level, I think functions that would act on that information can check if the content type is still one on which Workbench Access acts.

Revised patch.

Need to reverse the order of IF statements in the block.

I think the messages from Workbench Access should be suppressed when on a content type not controlled by Workbench Access.

In the newest patch, they should say "[Content type name] pages are not under access control".

That might be over-communicating, but it seems important.

Another question: How does this affect the dashboard Views?

More TODOs:

1. Implement hook_node_types_update().

2. Implement hook_node_types_delete().

3. Hide the field widget on Content Type manage fields screens if disabled for that content type.

Scratch items #1 and #2. They aren't needed. Node module handles that.

/me notes that @davereid was actually wrong about something....

Proper hiding of the field widget.

And a patch that removes restricted node types from Views and other elements.

Bumping to major, since this is a release blocker.

I think there is a problem with the query method in workbench_access_handler_filter_access.inc

I have three content types on my test site: article, page and news. Workbench Access is configured to ignore article nodes.

Here is a query that Views produces when using this filter.

SELECT node.title AS node_title, node.nid AS nid, node.type AS node_type, node.status AS node_status, users_node.name AS users_node_name, users_node.uid AS users_node_uid, node.changed AS node_changed, node.uid AS node_uid
FROM 
{node} node
LEFT JOIN {users} users_node ON node.uid = users_node.uid
WHERE (( (node.status = 1 OR (node.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1) AND (node.nid IN  (SELECT DISTINCT workbench_access_node.nid AS nid
FROM 
{workbench_access_node} workbench_access_node
WHERE  (workbench_access_node.access_id IN  ('news', 'page', '20', '21', '22', '23', '24', '25', '26', '27')) AND (workbench_access_node.access_scheme = 'taxonomy') )) AND (node.type IN  ('news', 'page')) ))
ORDER BY node_changed DESC
LIMIT 25 OFFSET 0

This query produces no results even though there are page nodes in the appropriate WB Accesss taxonomy. It looks like the problem is that second where clause. If I comment out this line:

$this->query->add_where(0, "$node_table.type", $allowed, 'IN');

Then I do get results. However, I also get results of article nodes that were assigned to these sections before article was disallowed from WB Access.

Interesting. That wasn't happening on the Workbench views, but only on a new custom View.

This patch moves that query element to the subquery, which is likely where it belongs.

Thank you for this. Exactly what I needed. Normally I have a menu with some views-pages, and the rest of the menu-structure is created with taxonomy_menu.
So the main menu could be:
main_menu
- home
- views-page-listing news
- views-page-listing events
- taxonomy-term topic1
-- taxonomy-term topic1.1
- taxonomy-term topic2
- taxonomy-term topic3

I applied the patch and it sems to work (did not do anything with views).

Thanks @avdp.

One more review to go, and then we can commit.

Queuing to review

Minor re-roll.

Re-roll to fix tests against head.

Committing, since tests pass.