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).
Thoughts?
Thanks,
-mike
Comment | File | Size | Author |
---|---|---|---|
#17 | 1191484-argument.patch | 1020 bytes | agentrickard |
#17 | workbench_access_handler_argument_access.txt | 2.02 KB | agentrickard |
#12 | workbench_access_taxonomy.png | 40.12 KB | ultimike |
Comments
Comment #1
ultimikeAfter 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 (http://drupal.org/node/1089494#comment-4596308), but I have confirmed that these issues are the same when I use 7.x-1.0-beta6.
Thanks,
-mike
Comment #3
agentrickardThe 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.
Comment #4
agentrickardContextual filters (nee "arguments" is a good feature request and should be worked here. The rest likely goes to #1187424.
Comment #5
ultimikeThanks 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?
Thanks,
-mike
Comment #6
agentrickardYes. 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.
Comment #7
ultimikeKen,
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 workbench_access.views.inc, 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?
Thanks,
-mike
Comment #8
agentrickardThat 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.
Comment #9
ultimikeKen,
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...
Thanks,
-mike
Comment #10
agentrickardWe're using one taxonomy, and then training clients why both form items are necessary.
Comment #11
ultimikeKen,
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:
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,
-mike
Comment #12
ultimikeKen,
I've attached a screenshot of the language I'm using to explain the two fields. Thoughts/suggestions/comments?
Thanks,
-mike
Comment #13
agentrickardHm, I wonder if we should _replace_ the taxonomy term form instead of using it.
Comment #14
ultimikeI'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?
Comment #15
agentrickardNot 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.
Comment #16
ultimikeGotcha. 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.
Thanks,
-mike
Comment #17
agentrickardSo 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.
Comment #18
philipz CreditAttribution: philipz commentedThe #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.
Comment #19
Fonkel CreditAttribution: Fonkel commentedIt 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?
Comment #20
Wappie08 CreditAttribution: Wappie08 commentedin 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
Comment #21
ronny89 CreditAttribution: ronny89 commentedSince 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. ;-)
Comment #22
agentrickardIf 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.
Comment #23
IPdNYourCheerios CreditAttribution: IPdNYourCheerios commentedWorkaround 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):
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. =)
Comment #24
agentrickard@IP
1) I think that post is entirely off-topic here.
2) #1187424: Default taxonomy form support is the better solution to the problem.
Comment #25
Divya Rathanlal CreditAttribution: Divya Rathanlal commentedI 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.
Subscribing!
Comment #26
MrSasquatch CreditAttribution: MrSasquatch commented@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.
Comment #27
agentrickard@TheSasquatch
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.
Comment #28
MrSasquatch CreditAttribution: MrSasquatch commentedI 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.
Comment #29
agentrickardThanks for that ;-)
Comment #30
MrSasquatch CreditAttribution: MrSasquatch commentedPerhaps 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? ...like a taxonomy field for that term? Please help. Thanks!
Comment #31
agentrickardPlease don't cross post.
Comment #32
DevElCuy CreditAttribution: DevElCuy commentedPatch at #17 works like a charm if you add it to a custom module, using hook_views_data_alter():
Comment #33
agentrickard"Works like a charm" doesn't really address any of the questions raised in #17.
Comment #34
MrSasquatch CreditAttribution: MrSasquatch commentedI 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.
Comment #35
agentrickardIn 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:
Comment #36
MrSasquatch CreditAttribution: MrSasquatch commentedagentrickard, 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?
Comment #37
agentrickardYou 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.
Comment #38
richardbporter CreditAttribution: richardbporter commentedWhat 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?
Thanks!
Comment #39
chris.smith CreditAttribution: chris.smith commentedagentrickard - 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?
Comment #40
agentrickardDisable "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.
Comment #41
chris.smith CreditAttribution: chris.smith commentedThanks. Got it working. Works like a charm with the contextual filters.
Comment #42
tswaters CreditAttribution: tswaters commentedIn 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 'workbench_access_handler_filter_access.inc' to fix this :
Of course, I had to rename "$table" because that variable name is used in the subquery.
Comment #43
nubeli CreditAttribution: nubeli commentedFor our own purposes we created a module based on #17, which we've posted here: https://github.com/freeform/workbench_access_context. 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.
Comment #44
karthiselvam.seeralan CreditAttribution: karthiselvam.seeralan as a volunteer and commentedHello 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?
Thanks,
Karthiselvam Seeralan.