Default taxonomy form support

By "default taxonomy form" are you referring to a default taxonomy field? My issue with this module is that, while it's very easy to set up and use, it appears to ignore the taxonomy terms assigned to each node. Instead, it creates the new node edit form element where you select the editorial section. Not only is this limiting (since you can currently only select one editorial section) but it means that all the content on the site which already has associated taxonomy terms must be edited to match the selected editorial section with the assigned terms.

Testing this patch. Noticed that debug code is added in several places.

subscribing

subscribing

Updated patch to remove debugging code. My use case is default menu integration, so I'll be testing this against #1101638: Default menu form support

And the actual patch :)

I was referred to this issue by #1276792: Enable Hierarchical Select when multiple section assignments are allowed. But, reading through this, I'm not sure what it's really about. Something about how fields and taxonomy works...

Anyway, I can apply the patch from #14, but how should I test it? What is it supposed to do? What kind of tests would help you?

Subscribe

Patch #14 works for me but I needed to make a modification.

First it's not so obvious perhaps how to set it up. You need to go to admin/config/workbench/access/settings and uncheck "Require a Workbench Access form element". The second step is to add a taxonomy term reference field (to the vocabulary you're using for Workbench Access) to your content types. This forces Workbench Access to use (and filter) the taxonomy term field and not add its own.

The problem I had was with the language code in workbench_access.module file. After saving the term was assigned but error was displayed:

Notice: Undefined index: pl w workbench_access_node_presave()

and no section was attached. My node language ['pl'] was different from term field language ['und'].

I changed this line:
$data = $node->{$field}[$node->language];
to

$language = field_language('node', $node, $field);
$data = $node->{$field}[$language];

and all works fine.

Thanks duellj ! I didn't try your patch until now because I was trying to write my custom module to do the same thing but it was too specific :)

Re-rolled the patch from #14 with the changes suggested by @philipz in #20.

Tested with the default taxonomy widget and with Hierarchical Select 7.x-2.x-alpha5 in a multilanguage site and everything works great!

Fixed those exceptions.

This re-breaks the issue defined here: https://drupal.org/node/1256692

#20 explains how to use a taxonomy field.
If "Require a Workbench Access form element" is still checked, then the workbench section will not appear under a vertical tab.
If "Require a Workbench Access form element" is unchecked, then this patch functions as expected.

#24 works like a charm!

Found 1 problem though... those without permission are able to edit the access form. I've attached a pic to better explain.

The one on top is the default workbench access form and the one below it is the term reference field. Further testing raises the question, how do you control who can change/view the access group(s)? Or am I missing something?

Update: Is it suppose to be the following permission that controls who can see the form or not? If so, not working.

View Workbench Access information

Would it create update headaches if the "current"/next release temporarily relied on Field_property module?
If not, that could serve just to get such a feature "in", so that there will be more time to work out just how this could/should be handled internally without such dependency.

When saving the node after editing, the patch from #24 does not respect permissions that already exist.

Say, you have a "Node" associated with "Term1" and "Term2".
The "Editor" is associated only with "Term1".
(See attachment.)

So, when the "Editor" changes the "Node", he/she is allowed to (re)associate the "Node" only with "Term1".
Thus, as soon as the changes are saved by the "Editor", the "Node" loses its' association with the "Term2".

Any ideas how to avoid this?

there should be an automatic check for that on node save:
- nobody should be allowed to remove terms they are not permitted to use

Perhaps I'm missing something, but what's the problem with (pseudo-code):

if(module_exists('taxonomy')) {
  // do code
}
else {
  drupal_set_message("You must first enable the Taxonomy module in order to select this option");
}

?

Looks like the right direction, but that's a lot of code to review, will look at applying it into our dev environment on Monday. Meanwhile, I can at least say that the patch applies cleanly to a dev checkout and doesn't appear to have broken anything.

Personaly, I would push towards removing the autocomplete fields, as I can't see it adding enough value to be worth the trouble, but that's just my two cents.

Many sites have lots of taxonomy terms where the lack of autocomplete support would come close to a showstopper. It is not uncommon to have 200+ terms in a vocabulary.

I'd vote for following a permission model, perhaps similar to how http://drupal.org/project/active_tags active tags does it.

I wouldnt worry about that kind of burden on admin shoulders, as long as it comes with logical gui and configuration options - which is important to get right, and, of course - a real challenge.

The screenshots in #36 looks promising;
- what would the brief description/guideline text below each of the "News access control field" and "Basic access control field" be?

Requesting another review by @stevector. Assigning. Other issues are relying on the completion of this one. Raising priority to major.

    Notice: Undefined index: en in workbench_access_node_presave() (line 649 of drupalroot/sites/default/modules/workbench_access/workbench_access.module).
    Warning: Invalid argument supplied for foreach() in workbench_access_node_presave() (line 654 of drupalroot/sites/default/modules/workbench_access/workbench_access.module).

I got this error when saving a node. I have Workbench Moderation also enabled. I'm not sure if that is a factor. The problem seems to be that

$node->language is set to "en" and my taxonomy field is keyed on "und." Can someone with more experience on Drupal's language handling chime in with how that should be straightened out?

When applying the patch in #40, I get the following when viewing a taxonomy page:

Fatal error: Maximum function nesting level of '100' reached, aborting! in [basepath]/includes/database/database.inc on line 907

Call Stack:
    0.0001     644424   1. {main}() [basepath]/index.php:0
    0.0034    1396360   2. drupal_bootstrap() [basepath]/index.php:20
    0.0397    8721760   3. _drupal_bootstrap_full() [basepath]/includes/bootstrap.inc:2101
    0.1697   34272464   4. menu_set_custom_theme() [basepath]/includes/common.inc:4944
    0.1697   34272512   5. menu_get_custom_theme() [basepath]/includes/menu.inc:1691
    0.1701   34277208   6. menu_get_item() [basepath]/includes/menu.inc:1676
    0.1704   34289168   7. _menu_translate() [basepath]/includes/menu.inc:458
    0.1704   34289696   8. _menu_load_objects() [basepath]/includes/menu.inc:746
    0.1704   34290696   9. taxonomy_term_load() [basepath]/includes/menu.inc:579
    0.1704   34291216  10. taxonomy_term_load_multiple() [basepath]/modules/taxonomy/taxonomy.module:1214
    0.1704   34291296  11. entity_load() [basepath]/modules/taxonomy/taxonomy.module:1147
    0.1712   34458376  12. DrupalDefaultEntityController->load() [basepath]/includes/common.inc:7473
    0.1718   34531072  13. SelectQuery->execute() [basepath]/includes/entity.inc:196
    0.1718   34531072  14. SelectQuery->preExecute() [basepath]/includes/database/select.inc:1279
    0.1718   34532128  15. drupal_alter() [basepath]/includes/database/select.inc:1257
    0.1719   34534800  16. workbench_access_query_term_access_alter() [basepath]/includes/module.inc:1004
    0.1719   34534800  17. menu_get_item() [basepath]/sites/all/modules/contrib/workbench_access/workbench_access.module:1988
    0.1722   34544040  18. _menu_translate() [basepath]/includes/menu.inc:458
    0.1722   34544568  19. _menu_load_objects() [basepath]/includes/menu.inc:746
    0.1722   34545568  20. taxonomy_term_load() [basepath]/includes/menu.inc:579
    0.1722   34546088  21. taxonomy_term_load_multiple() [basepath]/modules/taxonomy/taxonomy.module:1214
    0.1722   34546168  22. entity_load() [basepath]/modules/taxonomy/taxonomy.module:1147
    0.1722   34546216  23. DrupalDefaultEntityController->load() [basepath]/includes/common.inc:7473
    0.1724   34561600  24. SelectQuery->execute() [basepath]/includes/entity.inc:196
    0.1724   34561600  25. SelectQuery->preExecute() [basepath]/includes/database/select.inc:1279
    0.1724   34562656  26. drupal_alter() [basepath]/includes/database/select.inc:1257
    0.1724   34563808  27. workbench_access_query_term_access_alter() [basepath]/includes/module.inc:1004
    [snip]

It's odd, because the menu item is supposed to be cached the first time, so it shouldn't be running taxonomy_term_load each time (triggering the infinite loop).

i tried to apply the patch without success (the applying itself actually worked).

(plenty error messages)

in both cases calling /admin/config/workbench/access/settings eventually showed up nothing but a blank window.

sorry, you are right, i patched the 7.x-1.0 release.

so, i installed the current 7.x-1.x-dev.
after patching this, there are no more error messages, but still the settings screen doesn't show up.

1. as mentioned above the admin/config/workbench/access/settings-page. the three others do work and show expected behaviour.
2. in admin/reports/dblog nothing is reported. i do not have access to logs on the server, but i could ask for it.
3. yes, it was / still is configured. just as i had done an upgrade.
4. yes.
5. nothing unusual.

yes, it's enabled too.
may i provide more detailed debugging information in any form?
btw, i also checked the "source view" of the client browser. it's purely blank.

Marked #1341654: Make worflow_access field configurable (via term-reference?) as a duplicate of this issue.

@agentrickard

The patch at #52 seems to be working fine for me.

Surely there must be a permission to check for regarding the autocomplete?

What is the effect of doing nothing about that part; - just let the user try to save the form with several new terms, and then get an error that prevents saving the form?
As long as 1) that message is understandable for novice users, and 2) the terms entered are not lost, but retained so it is possible to edit/correct and copy/cut the terms that are preventing the save, then perhaps it is ok to do nothing.
- hmmm, can they be visually emphasized (identified), or controlled against the dropdown after the error occurs? If having entered 10-15 tags, and number 3,7 and 12 are new, how to identify them conveniently?

Edit:
- this makes me wonder if the Active_tags module (or one of its competitors) could come in handy here: would it be possible through such a widget to make sure that the new tags were emphasized somehow?
- notice: #1257268: Active Tags does not remember tags on form submit if form doesn't validate
- and this will have to go in too first: #1229538: Please add a js fallback
- http://drupal.org/project/active_tags
- http://drupal.org/project/autocomplete_deluxe

#59: experienced the same problem here.
No messages in the PHP logs.
Drupal logs stated: "Warning: require_once(.../drupal-7.9/sites/all/modules/workbench_access/workbench_access.admin.inc) [function.require-once]: failed to open stream: Permission denied in menu_execute_active_handler() (line 501 of .../drupal-7.9/includes/menu.inc)."

Solved it by flushing the cache.

I second that.

Confirmed this is working as expected. I might have a follow-up or two for a couple cleanups for code, but let's get this in.

@65 hm, neither have still any message nor does flushing help.
btw, i turned off as many modules as possible, but still don't get that settings-page.

Looks as if there was a lot of work devoted to this issue (many thanks) and I know this is now labelled as fixed, but there hasn't been an official update of this module since August, 2011. Will there be one soon, or will I have to install the dev version to get this to work?