I read from this issue that the way to get a workflow access exposed filter on your view is to tag the view with "workflow". I'm not sure why this was necessary in the first place, but it would be great if we could have it as a normal views filter so that I wouldn't have to scower the issue queue to find out how to get the magic to happen :)

Comments

alexverb’s picture

I second this request. Just like adding the field to a table view you don't really give the user any option. I think the hook_views_pre_view should be burried. People are smart enough to add their own filters and fields to a view. And since there is a filter and field defined it can be burried almost immediatly.

The only thing that needs to happen is a rewrite of the filter so that the user can choose to filter on any section OR the user sections. That would give a lot more flexibility in this module.

agentrickard’s picture

I agree. It means replacing the "magic" with a hook_views_default_views_alter() or similar in the main module.

This code was originally added to allow the default Workbench views to respond to the addition of Workbench Access. However, Views 3 is much more stable now, so we have better ways to handle this.

jenlampton’s picture

It looks like we already have a views filter and a views field, but they act as though the relationship to workbench_access data is required. Can we separate the relationship from the filter, so that it can be optional (when exposed)?

I'm having trouble getting both content affected by workbench_access and content not affected to appear in the same view.

Also, I think maybe the hook_views_default_views_alter() function should remain in workbench_access, since it's the source of the data we're adding to the views, no?

roynilanjan’s picture

But when I expose this work-bench field in a view the search on the basis of this filter not working
Can you please tell me where I'm wrong

agentrickard’s picture

Please attach an export of the view.