I'm not sure which module should support which one, but currently Hierarchical Select does not respect Workbench Access taxonomy term access restrictions. If Workbench Access is in "taxonomy mode", access to specific terms should be restricted when editing nodes. Workbench Access plays nicely with core taxonomy select list and autocomplete, but not with HS.

Since HS had similar code to support term_permissions module, patching HS seemed to be the easiest way to accomplish this. Maybe it would be generally wiser to trigger some kind of hooks for modules to let them alter term selections.

This patch introduces three times almost the exactly same code, so most of the logic would be best to be moved to a helper function. Somebody can work it from here if needed.

Patch attached.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

juhaniemi’s picture

Status: Active » Needs review
alexkb’s picture

Issue summary: View changes

@juhaniemi, great patch! Very glad someone else has the need of hierarchical_select + workbench_access.

Applying the patch to my version of workbench wasn't clean, but when I manually did it, I was seeing the following (using PHP 5.4):

Notice: Trying to get property of non-object in hs_taxonomy_hierarchical_select_root_level() (line 622 of hs_taxonomy.module).

To fix, I just added "if (count($terms) > 0) {" before trying to call next($terms).

  // If the Workbench Access module is installed, honor its term permissions.
  if(function_exists('workbench_access_get_user_tree')) {
    if(variable_get('workbench_access') == 'taxonomy') {
      // Get vocabulary machine name from first term
      if (count($terms) > 0) {
        $vocabulary_name = next($terms)->vocabulary_machine_name;
        ..
        ..
      } // if our terms array is populated
    }
  }

  return _hs_taxonomy_hierarchical_select_terms_to_options($terms);
}
alexkb’s picture

One problem we're having (which is not to the fault of your patch) is that users will see all child sections of a parent section they have access to even if they don't explicitly have access to the child sections.

If you don't give the user access to the parent section, but do to a child section, the hierarchical_select widget doesn't give the user the chance to select the child section.

Attached is a patch for workbench_access which limits the child terms. A new setting (workbench_access_depth_ignore) has to be introduced though, so that the child terms (which has no access restrictions in place) of the child term (that does) are still selectable. I'm not sure that this approach is a good idea, but I can't figure out an alternative solution at present.

If you switch to a "select list" widget for your section field, it's all different. This patch doesn't affect that widget for some reason (must be another hook altering it I think). Will re-assess tomorrow.

alexkb’s picture

Just an FYI for others coming across this thread: there is also the Workbench Access Hierarchical Select Section Assignment module which appears to assist in bringing both the workbench_access and hierarchical_select modules together. I haven't used it yet, as we're too far down the rabbit hole to be trying a new solution at this point, but it might help others wishing to use these too very powerful modules together rather than applying hacky patches like mine. Cheers.

samhassell’s picture

Cool patch.

$vocabulary_name = next($terms)->vocabulary_machine_name;

should use current() instead of next() because there may only be one term, and next() will raise a warning in that case.

Patch attached

alexkb’s picture

+1 #5 patch for hierarchical_select.

Re: #3 - in terms of support for workbench_access, I've redone this over on the workbench_access queue here: #2288859: hierarchical vocabs and inheriting access - as it actually applies to all widget types. You may notice the depth ignore setting was taken out, as it was much too hacky.