Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have taxonomy_access installed, when creating new node, only limited terms displayed at Hierarchical Select box, but as soon as I choose any item, the first drop down list will show all terms instead of limited, and I am able to choose any term.
Comment | File | Size | Author |
---|---|---|---|
#3 | add_taxonomy_access_support.patch | 2.21 KB | mastervissie |
Comments
Comment #1
Wim LeersTaxonomy Access is not supported by HS. Term Permissions is.
If you roll the patch to add support for this, I'll gladly commit it.
Comment #2
Wim LeersComment #3
mastervissie CreditAttribution: mastervissie commentedHere is a patch that fixes this problem for Taxonomy Access Control. It adds the value of the current $_GET['q'] variable to the $_POST variable array. When the hierarchical_select_json page is accessed, the $_GET['q'] variable is replaces by the given variable from the original page. So when Taxonomy Access checks the q-var, this is the q-var from the original page.
Patch file created to the latest dev.
Comment #4
Wim LeersI don't see how this could add Taxonomy Access integration.
Comment #5
Wim LeersClosing due to lack of response.
Comment #6
ayalon CreditAttribution: ayalon commentedDear Wim Leers
I had exactly the same requirements as stated in the starting post. Then I found this thread and also reviewed the patch. My first reaction was exactly the same as yours: The patch has nothing to do with taxonomy access control. ?!??!?
Then I debugged hierarchical select and taxonomy access to find out, why hiearchical select fails using taxonomy access.
My testcase:
Vocabulary with two hiearchy layers
Home (create)
- Maintopic (create)
--Subtopc 1 (create)
--Subtopic 2 (no access)
I wanted to allow a user, to create/add nodes only on the taxonomy Subtopic 1.
If I selected the second hiearchy, HS always displayed all taxonomy terms including Subtopic 2, which was wrong.
The reason for this behaviour is the following:
- If you select a sub hierarchy, a AJAX call is made on a specific url (q GET).
- HS then enters the function _hs_taxonomy_hierarchical_select_get_tree() to fetch the taxonomy tree
- In line 791 a db_rewrite_sql() is made.
- If you fetch the taxonomy from the URL 'node/add/page' everything is fine
- If you fetch the taxonomy from the URL of the AJAX call, taxonomy access fails, because the db_rewrite_sql() comes with a different q GET parameter
Please check the function taxonomy_access_db_rewrite_sql():
- On a node/add url the $op becomes 'create' and other terms are fetched.
- With the HS AJAX call, the POST URL is different and all terms are returned instead of the limited terms.
In short:
Taxonomy Access checks the URL of the page, where terms are fetch in th database. If the URL is a node/add page, the behaviour is correct, if the URL is a AJAX callback, the behaviour is wrong.
Conclusion:
The patch is simply genius. It's a FULL taxonomy access control implementation in hierarchical selct and works exactly as described with no side effects.
Please test it and include the patch in the next release.
Comment #7
Wim LeersThis needs to be reviewed first, it's not yet RTBC.
Comment #8
ayalon CreditAttribution: ayalon commentedI have this patch now for months on huge live site and it works as expected.