0

We have created a vocabulary with terms this way:

(main term A)
  |
  +-- subterm A1
  +-- subterm A2
  +-- ..
  \-- subterm A3

(main term B)
  |
  +-- subterm B1
  +-- subterm B2
  +-- ..
  \-- subterm B3

Easy right?

Then we've created "main terms" roles. Then we've used the taxonomy_access for those "main terms" roles. I.e. The rôle called main term A will only be allowed to create subterms of the main term A term.

Easy right?

Now we need reviewers. So we've "split" "main terms" roles in two:

  • "main terms A contributors"
  • "main terms A reviewers"
  • "main terms B contributors"
  • "main terms B reviewers"
  • ...

And we've used the workbench module to give rights to contribute / or / review. The problem is that the rights given are not detailed enough: if you give "main terms reviewers" the right to "review", he/she is allowed to review all the "needs-review" nodes. Example: "main terms A reviewers" have the "review" right, so (like it is now) they have the right to review all "needs-review" nodes. We'd like them only to see/review only the nodes based on their roles: "main terms A reviewers" should only be allowed to review "main terms A needs-review" nodes. We could have used the workbench_access but this would implie create a section for each "main terms". This would kind of force us to duplicate all our "main terms" into "sections" then give "sections" right.

How would you do?

Maybe there's another possibility: the workbench tab is a view. So maybe it could be possible to add a filter based on the taxonomy access control, but it seems that taxonomy access control has no api, and we should have to create a manual join. Maybe there's a way to create a fully customized join based on the taxonomy access control? If so, may I ask how you would do this?

If you think I'm not on the right track, don't hesitate to give me your solution!

Thank you!

0

I think the easiest option is leave everything as you have it in terms of configuration and your taxonomy term values for main terms. The default Workbench (Moderation) logic isn't nested enough for you. So use it's supported hooks to extend the functionality to meet your needs.

Look at hook_workbench_moderation_access_filter()

/**
 * Allows modules to alter moderation access.
 *
 * @param &$access
 *   A boolean access declaration. Passed by reference.
 * @param $op
 *   The operation being performed. May be 'view', 'update', 'delete',
 *   'view revisions' or 'moderate'.
 * @param $node
 *   The node being acted upon.
 */
function hook_workbench_moderation_access_alter(&$access, $op, $node) {
  global $user;
  // If the node is marked private, only let its owner moderate it.
  if (empty($node->private) || $op != 'moderate') {
    return;
  }
  if ($user->uid != $node->uid) {
    $access = FALSE;
  }
}

By implementing this hook for the node access check, you can define the nested taxonomy check you're wishing Workbench_Moderation did for you. In order to find if some node has a value of a certain parent term you may find the Taxonomy Edge API module useful. Then again you might not need Taxonomy Edge.

I believe the Views workbench uses will also support this runtime check.

  • Thank you very much for your answer, it's what i was looking for. – Olivier Pons Feb 1 '13 at 9:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.