The Workbench Access module currently has a "Workbench Access: Section" Views field, a "Workbench Access: Access filter" Views filter, as well as some other Views integration, but I believe it is missing something that would be very useful to a wide variety of users: a contextual filter for Views.

Imagine if you will...

A site has a number of content types that are controlled by Workbench Access. Each node is (obviously) assigned to a Workbench Access "section". Ideally, site admins would be able to create a view that accepts a Workbench Access "section" as a contextual filter in order to reuse the view in various "sections" of the site. Currently (I believe), each "section" needs to have their own dedicated view with a standard Views filter hard-coded to each "section" (I heart air-quotes).



Members fund testing for the Drupal project. Drupal Association Learn more


ultimike’s picture

After working with Workbench Access for some additional time, I have a more general question: assuming that my "active access scheme" is a taxonomy, shouldn't I be able to utilize that same taxonomy in other areas of my site as well?

For example, I have several published nodes assigned to a particular Workbench Access "section" - but when I go to that term's standard Drupal display page (taxonomy/term/[term_id]), I get the standard "There is currently no content classified with this term" message. This occurs for all terms except the top-level terms.

As another example, when I build a simple view to display content and all their terms, the terms in the "active access scheme" taxonomy do not appear unless they are on the top level. The same goes for when I use the "active access scheme" taxonomy as a Views filter.

I feel like I'm missing something really basic here.

For the record, I am using the latest version of Workbench Access from HEAD with the multi-select patch installed (, but I have confirmed that these issues are the same when I use 7.x-1.0-beta6.


agentrickard’s picture

The test scheme provided by the module is not "owned" by the Taxonomy module, and may not behave as expected. So, no, you can't use it elsewhere. You can thank FieldAPI for that.

The default form does not save anything to taxonomy field tables, either, since that is revisioned data and would break access controls. See #1187424: Default taxonomy form support for work on using default fielded taxonomy forms.

So currently, both the taxonomy and menu schemes only use the hierarchy-building mechanism. They actually save the data separately.

Views filters for access schemes should be restricted to the sections and their children that your user has access to.

agentrickard’s picture

Contextual filters (nee "arguments" is a good feature request and should be worked here. The rest likely goes to #1187424.

ultimike’s picture

Thanks for the quick replies - most of what you said makes sense, but some of it is a bit over my head.

Allow me to explain what I'm attempting to do and maybe you can point me in the right direction:

1. I create a new "section" hierarchical vocabulary. Each term corresponds to a section of the web site. Let's assume the taxonomy looks like this:

- Main
-- Topic 1
-- Topic 2
--- Subtopic 2.1
--- Subtopic 2.2
-- Topic 3
--- Subtopic 3.1

2. I make this vocabulary my active access scheme.

3. I "enable moderation of revisions" for the "article" content type and create a bunch of article nodes and assign them to various sections.

4. At this point, all I want to do is create a view that filters articles by section. Is this possible?


agentrickard’s picture

Yes. The easiest way to do this (right now) is a little odd. If you TAG your View "Workbench", the filter should be added for you.

The Workbench Moderation module already supplies such a view.

ultimike’s picture


Thanks for all your help so far - it is much appreciated.

I went ahead and added "Workbench" as the view tag, but I'm not sure if anything changed. I was looking at the code in the workbench_access_views_pre_view() function in, and I see where all this is happening, but it looks like the filter will only be added to "table" styles, correct? Plus - that's an exposed filter, correct?

I'm trying to use Workbench as it was meant to be used - I think. Perhaps I'm missing a fundamental point to it - should I be using two different taxonomies? One for the for the Workbench Access scheme and the other to organize my site content the traditional way? In my case, these two hierarchies are exactly the same.

In the big picture, here's what I'm trying to do: override the standard taxonomy term pages (taxonomy/term/[term_id]) with a panel page, set the term ID as a contextual argument in the panel, then have a number of views that utilize the term ID as a contextual filter. Ideally, the term ID will come from the Workbench Access scheme, but it sounds like this isn't possible.

What do you think?


agentrickard’s picture

That won't be possible until #1187424: Default taxonomy form support is fixed, which is a very nasty issue. Until that time, you can use a single vocabulary, but will have to administer two form elements on each node.

In the meantime, you still need a contextual filter, I think.

ultimike’s picture


Understood - that makes sense. Looks like we'll have to use two form elements on each node.

Just out of curiosity - do you have any idea if sites that use Workbench generally use two different taxonomies? One for workbench access and traditional site organization? How are other sites dealing with this issue? I've been assuming that my use case is a pretty typical one...


agentrickard’s picture

We're using one taxonomy, and then training clients why both form items are necessary.

ultimike’s picture


Perhaps I need some "client training" as well (heh)!

I understand that Workbench Access "does not provide any content filtering of access restrictions for users trying to view that content" - I'm trying to wrap my head around how best to describe this to clients in a succinct way. I suppose it goes something like this:

Workbench Access restricts who can edit a given piece of content, but does not limit them to where the content can appear on the site.

Wouldn't it be possible to write a small custom module that hides the "taxonomy term" field on node forms and then, on form submission, populates it from the selected options on the "workbench access" field? Wouldn't this have the desired effect that I'm looking for (one visible field controlling both editing and viewing)?

Thanks again for all your help,

ultimike’s picture


I've attached a screenshot of the language I'm using to explain the two fields. Thoughts/suggestions/comments?


agentrickard’s picture

Hm, I wonder if we should _replace_ the taxonomy term form instead of using it.

ultimike’s picture

I'm not sure you want to replace it - if you do that, then the site admin modifies the taxonomy, the access scheme will get out of sync, correct?

agentrickard’s picture

Not if automated section assignments are turned on. But still, each vocabulary should have a separate form element, so that's a non-started.

The text you have right now, by the way, is basically what we use.

ultimike’s picture

Gotcha. Thanks again for your help - I'll report back with any feedback from the client as to the wording in hopes of helping somebody else out in the future.


agentrickard’s picture

Status: Active » Needs work
2.02 KB
1020 bytes

So the contextual filter turns out to be a real problem. Since this is really an _editorial_ access control tool, do we need to filter out content based on who the user is or just based on the current context?

And how to determine the current context? For menu, that's fairly easy. But for taxonomy, it's a challenge.

So simple first steps attached.

Move the .txt file into workbench_access/includes and change the extension to .inc.

philipz’s picture

The #12 screenshot shows great way to "hide" this problem from the client. There is however another issue and that is obviously a possibility to post content anywhere on the site though the user has only rights to assign the content to Human Resources editorial group?
In my case this is useless. Please correct me if I'm missing something.

Fonkel’s picture

It would be nice to have a view populates or changes the value of a field depending on the value of another field.
This is my use case:

I use workbench for a workflow setup. Workbench access uses taxonomy for section access.
Te filter content for a particular section (e.g. all calender-items for the youth in the youth section) I need a contextual filter.
But there are some issues to expose the the field used for workbench access as a contextual filter.
Till there is a solution, I need a workaround, so this idea came up:

The contentype has a field, that is populated on node-submit with the value of the taxonomy name that is used for workbench access.
When a node is updated, and the section is changed, this extra field is updated also.

This gives the opportunity to filter (contextual) the results to a particular section, without the site contributors to have to fill in 2 fields.

How do I get this done?

Wappie08’s picture

in reaction to #17:

I think there are two contextual filters needed:
for user views: - current (user) context
for content views: - current (node) context

Actually I saw similar filters for custom fields in the d7 og module (different contextual filters for users and for content).

I am very much interested in a solution for the menu at first. This would make it possible (and very simple!) to use a content-type "news" and making it possible for authors to produce news for their own section (shown on their section page).

Actually I'm kinda interested: how is it possible to control the display of nodes? I know this is an "editorial" module but I cannot figure out the use if an admin had to add pages manually to a menu.. For me this module stays unusable until #1101638: Default menu form support is there.

Greetings Wappie

ronny89’s picture

Since I eventually found myself more or less in a situation like some others here, I hook in here. I hope it's the right place.

And after reading through this thread several times (English isn't my mothertongue) I'm still not sure whether I'm facing a bug here or I'm missing something in the concept.

What I want to do is simply what is described in comment #5. I also tag the view(s) with "Workbench" (as proposed in comment #6) and since then filtering by Section works. But as noticed in comment #7 an exposed filter that is neither desired nor configured appears on top of the view(s). Unfortunately there is no response to that.

So, is this a bug? Or is there a way to make the filter disappear?

Of course I think that the initial idea of this issue is a clever approach, but think that first way should be a simple way to display all content of a section that works. The Workbench modules that I use are just too tight to let one fail in sight of the goal.

If I just missed something fundamental, maybe a more detailed documentation on views integration would do it. ;-)

agentrickard’s picture

If you tag the View 'Workbench" and Workbench Access is enabled, that filter is added automatically.

This is a workaround for how to provide conditional filters to exported views. In your case, you probably _don't_ want to tag the View "Workbench" and add the filter manually.

However, this issue isn't about Filters, it's about Contextual Filters (which used to be called Arguments in Views), and the code needs work.

IPdNYourCheerios’s picture

Workaround for the needing 2 fields thing:

Problem: You can't filter nodes in a view based on the Workbench Access "section" assigned to them (as far as I know). The supplied "Workbench Access: Access filter" partially works for this, but it will only display nodes if the user has editorial privileges to the category. In the case of anonymous users, nothing shows up.

Workaround Idea: Create an additional taxonomy (Term Reference) field to hold a duplicate of the "section" selected in the drop-down provided by Workbench Access. We can then use standard Views filters and our new field to separate content into sections. The goal here is to automate/hide the duplicate filed from the end user.

Solution (until hopefully this functionality is added to the module):

  • Install the Rules and Rules Autotag modules.
  • Add a "Term Reference" field to the content type you plan to organize into sections. This filed will later hold a duplicate of the taxonomy term(s) chosen in the Workbench Access "section" drop down (on the node create form). IMPORTANT: you must set the "number of values" to "unlimited". Be sure to choose the same vocabulary you're using for Workbench Access.
  • Create a new rule:
    • Events: Before saving content, After updating existing content
    • Conditions: Content is of type "Article" ***or whatever content type you chose to modify***
    • Actions: action set: Autotag to terms list ***bottom of the list***
      • Value: [node:workbench-access-sections] ***depending on how you have workbench access configured, you may need a different value here. You should be able to find yours by expanding the "replacement patterns" link and looking through the list***
      • The vocabulary used for extraction: ***choose the vocabulary you're using with Workbench Access***
      • Target list for storing extracted terms: ***click the "switch to data selection" button then click the down arrow next to the "data selector" field. Click "Node...(saved content)". Click the field name representing the taxonomy (term reference) field we created earlier. In my case, I named the field "field-section" so I clicked "Node-field-section" (You'll probably see 2 listed, choose the one without the "...")***
    • Save your Rule
  • At this point, when you save or update a node, the value of the Workbench Access "section" should automatically be copied into your new field. Now all you need to do is turn off the display of the field and use CSS to hide it on the node creation form (display:none;). You can then create Views that use your new field to separate your content into sections.

Hope that made sense/helps. Disclaimer: I just came up with this solution today, so it hasn't been tested extensively or in a production environment. Your mileage may vary, use at your own risk. =)

agentrickard’s picture


1) I think that post is entirely off-topic here.

2) #1187424: Default taxonomy form support is the better solution to the problem.

Divya Rathanlal’s picture

I would also be interested in contextual filter for workbench access. I am building an intranet site and would like to pull content based on the sections dynamically - so that events specific to the department are listed.

MrSasquatch’s picture

@IPdNYourCheerios, I would just like to thank you for your solution you posted in comment #23. That works beautifully. Is it ideal? No. Ideally Workbench Access taxonomy would behave like a true taxonomy that can be use to filter views. But your solution #23 gets the job done in an elegant and very dependable way. Best of all, if this aspect of Workbench Access is ever fixed, I can just change all my views to use the new method and drop the extra term reference field and rule that I set up.

@IPdNYourCheerios, I'll do you one better... Instead of setting your rule's events to "Before saving content, After updating existing content," try using just one event: "After moderation transition." This seems to be much more reliable, whereas your method seems to be intermittent or require a second "save" to trigger the rule. And after all, content should not be showing up in views until it's "published" anyway, so "After moderation transition" makes a lot of sense. Of course, "After moderation transition" is only appropriate if you're using Workbench Moderation, which I am. :)

Wow! I thought I was totally screwed! I thought I was going to have to wait until some future release of Workbench Access to get things working. It's a miracle that I found this solution, @IPdNYourCheerios. Thank you, thank you, thank you!!!

...and might I add... The ability to use Workbench Access taxonomy as a true taxonomy, like to drive views filters, etc, is critical. People do *NOT* want to maintain two taxonomy fields for each node. Also, people want their taxonomy term selection limited to what they are supposed to have access to, and I thought that was the whole point of Workbench Access. A second taxonomy field with access to all terms would be a big mess for us—editors would be putting nodes into blogs and calendars they don't have access to, etc.

agentrickard’s picture


The problem is that Drupal 7's Field API makes using native taxonomy form elements for access control very, very difficult, which is why it wasn't included in the first release.

In D6, Taxonomy module inserted a predictable field into a node form. In D7, it does not, which is why you now have to register the fields you want to use for access control.

MrSasquatch’s picture

I see. Seems these are not easy problems to fix. Thank you for continuing to "fight the good fight" and produce a good product. For now, I'm really happy with the "rules" solution proposed by @IPdNYourCheerios. It's clean and reliable. Ideally it would not be necessary, but since it is, at least it's a solid solution. Best part is that I can "undo" the solution in the future very easily if the Workbench Access field suddenly because a contextual filter for views.

agentrickard’s picture

Thanks for that ;-)

MrSasquatch’s picture

Perhaps you would be so kind as to chime in on a separate question I have about Workbench Access? I posted it as a separate issue, but here it is for your convenience...

How can I specify a different URL alias token/value for come taxonomy terms? I'm currently using [node:workbench-access-sections]/[node:title] which works great. But sometimes the name of the Workbench Access section doesn't make a good URL alias pattern/token/value. For example, our "Distance Education" section does not want URLs like /distance-education/page-title. They want /online/page-title. Is there a way that I can tell URL Alias to use a different value instead? a taxonomy field for that term? Please help. Thanks!

agentrickard’s picture

Please don't cross post.

develCuy’s picture

Patch at #17 works like a charm if you add it to a custom module, using hook_views_data_alter():

function custom_views_data_alter(&$data){
  $data['workbench_access']['access_id']['argument'] = array(
    'handler' => 'workbench_access_handler_argument_access',
agentrickard’s picture

"Works like a charm" doesn't really address any of the questions raised in #17.

MrSasquatch’s picture

I guess I don't understand #17. What are the questions? Maybe if they were rephrased.

For me, the big issue is that people typically want to set a "category/section" taxonomy field once, and it should serve both the purpose of specifying access control *AND* information architecture/classification/taxonomy. It would be very redundant to have the same taxonomy show up twice in the node edit form—once for access control and again for classification so that views can filter based on it—especially when the same taxonomy term is chosen for both in 99.9% of cases.

To this day, I'm still getting by using a rule to update the redundant taxonomy field, which I then hide using CSS, so it appears to editors that there is only one taxonomy-related field, which is the Workbench Access field for content section. (See #23 above.) This has proven to be very reliable. But again, it should not be necessary.

I understand this is a difficult problem to fix. I'm just reiterating my issues.

agentrickard’s picture

In the -dev version, you can stop doing that and use a native taxonomy field for access control, which may solve this problem entirely. The problem is that FieldAPI made doing that very difficult, which is why it wasn't in the 1.0 release.

As for context, the questions are essentially:

  1. Is the default context the user's section list?
  2. Do we set context based on the $node data or the $user data or both?
  3. What do we do on non-node pages?
  4. What to do when multiple sections are assigned?
MrSasquatch’s picture

agentrickard, are you saying that I can stop using duplicate fields and hiding the duplicate? If so, how do you recommend I proceed? Our site is pretty well built out, but there's still a lot of content to build. Would it be easy to do it the new way with the native taxonomy field, or would that break what we have built so far? If it's easy to switch approaches, should I do it now with the dev version, or should I wait until the next release?

agentrickard’s picture

You should be able to switch over without difficulty -- but test it on a backup site first. The native taxonomy field is a bit harder to setup -- you have to register a term field for each node type, but if those fields already exist, it's simple.

Use the --dev version. The blockers to the next stable are all menu-related and pretty tricky.

rbp’s picture

What is meant by tagging your view "Workbench"? Does that still work with the latest dev version? If not, does the patch in #17 still work with the latest dev version?


chris.smith’s picture

agentrickard - Could you please describe the step you are describing in #37. I've updated to the development version and have created a term reference field for each content type. But, it doesn't seem to be restricting access to the users.

In the Workbench Access Settings, I've enabled "Require a Workbench Access form element". I also had to disable all the content types to prevent the default "Workbench Access" field from appearing on each content type. Unfortunately, regardless of my access settings, the user has the ability to add an edit content in any section. Am I missing a step?

agentrickard’s picture

Disable "require a workbench field"; that isn't what you want. You want the "Enabled Content types" and "Access control fields" settings on the same page. You have to "register" the fields for use with WA.

chris.smith’s picture

Thanks. Got it working. Works like a charm with the contextual filters.

tswaters’s picture

In found a slight issue with the class provided in #17 -- if the view is referencing a non-node table, there is an error about no 'nid' field on the base table. This is because the filter adds a where clause pointing nid on "$this->query->base_table" and is not checking for relationships

I ended up copying some of the code from '' to fix this :

      $table = $this->query->base_table;
      // Ensure that we have a proper table when using a relationship from a non-node base table.
      // @TODO: There may be cleaner ways to do this lookup.
      if (isset($this->view->relationship['vid'])) {
        $table = $this->view->relationship['vid']->alias;
      elseif (isset($this->view->relationship['nid'])) {
        $table = $this->view->relationship['nid']->alias;

Of course, I had to rename "$table" because that variable name is used in the subquery.

nubeli’s picture

Issue summary: View changes

For our own purposes we created a module based on #17, which we've posted here: Warning; it serves our specific purposes which means we didn't test or address all possible combinations with workbench access. In our case the client is basing all workbench access on the menu.

karthiselvam.seeralan’s picture

Hello All,

We are using workbench module and we implemented #17 points. However we are not getting workbench access filed in view module for contextual filter section. Can you please provide exact solution for this issue?

Karthiselvam Seeralan.