Jump to:
| Project: | Taxonomy Access Control Lite |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Concerning the issue #197656: TAC_Lite default access for new taxonomy terms, surge_martin suggested:
From an interface standpoint, I think the logical way to implement this would be to have an < all > option on the page for access control by taxonomy.
I'm not saying that implementing that would be easy, but to me, that would be the logical way to add it.
+1 for this feature, I'd find it useful too.
I think this is a specific feature request which could probably solve many other problems. I'm opening a this Feature request issue though, with proper title so that it's easier to find:
"All" option per vocab for by default access to All terms (and new ones automatically).
which means that access is no longer restricted by default to manually chosen terms, but granted to all those from a chosen vocab.
- This will ease tac_lite administration very much and make it more consistent: On big sites, we just can't go through all roles' + specific users' Tac_lite access_control pages each time a term carrying access rules is added.
- By the way, it will allow not to grant administer_tac_lite access right anymore to people who shouldn't have it.
Comments
#1
Here is a simple patch which implements the "all" option. This is tested with 6.x-1.3. I have done this very quickly, and I am not an expert on tac_lite, so use with caution.
Index: tac_lite.module
===================================================================
--- tac_lite.module (revision 409)
+++ tac_lite.module (working copy)
@@ -226,6 +226,9 @@
'',
true,
'<'.t('none').'>');
+ array_unshift($form['tac_lite_grants_scheme_' .
+ $i][$rid][$vid]['#options'], (object) array('option' =>
+ array('-1' => '<all>')));
}
}
@@ -484,7 +487,8 @@
// Note that if tac_lite is configured, but no schemes support grant_view,
// we assume everyone can view all terms.
- if (count($tids) && is_array($vids) && count($vids)) {
+ if (count($tids) && is_array($vids) && count($vids) && !in_array(-1,
+ $tids)) {
switch ($primary_field) {
case 'tid':
// prevent users from seeing terms they do not have permission to read.
#2
Just from a quick look, I think your patch is bad in that selecting
<all>for any vocabulary would allow the user to see all terms in all vocabularies.Also you look for the
<all>in hook_db_rewrite_sql, but not in hook_node_grants.To properly implement this, you'd need to work with grants that are based on vids, in addition to those based on tids. I think this is a candidate for a module in tac_lite/contrib/.
#3
Yes, you are absolutely right. We only have one vocabulary that we are managing with this, so it is fine for us. I suppose a very quick-and-dirty fix, is to use negative numbers as $vids. For example:
Index: tac_lite.module
===================================================================
--- tac_lite.module (revision 409)
+++ tac_lite.module (working copy)
@@ -226,6 +226,9 @@
'',
true,
'<'.t('none').'>');
+ array_unshift($form['tac_lite_grants_scheme_' .
+ $i][$rid][$vid]['#options'], (object) array('option' =>
+ array(-$vid => '<all>')));
}
}
@@ -489,7 +492,7 @@
case 'tid':
// prevent users from seeing terms they do not have permission to read.
$join = "LEFT JOIN {term_data} tac_td ON $primary_table.tid = tac_td.tid";
- $where = "$primary_table.tid IN (". implode(', ', $tids) .") OR tac_td.vid NOT IN (". implode(',', $vids) .")";
+ $where = "$primary_table.tid IN (". implode(', ', $tids) .") OR -tac_td.vid IN (" . implode(', ', $tids) . " OR tac_td.vid NOT IN (". implode(',', $vids) .")";
return array('join' => $join, 'where' => $where);
break;
#4
Subscribing. Interested in this for Drupal 6. Would be a real time saver.
#5
The approach of this patch is not correct. It only addresses the sql rewrite portion of tac_lite, and not the node_access.
The proper implementation would add additional rows to the node_access table for a vocabulary id (rather than a term id). I don't think it's particularly difficult, and could be implemented entirely in an add-on module (either stand-alone or a sub-module of tac-lite). Anyone interested in writing that?
#6
subscribing
#7
subscribing
#8
I'm going to take a crack at this.
#9
I didn't have time to work on this. My workaround was to make it a hierarchical vocabulary, with every term nested under a term called ALL. In conjunction with hierarchical_select.module set to save term lineage, this provided an easy way to automatically grant rights to every term.
#10
Subbed. Using Tim's workaround in #9 above, but I'd prefer to be using a flat vocabulary rather than hierarchical.
#11
Yikes. What a bummer!
I think adding the ALL option to terms lists, would probably be the smallest rework.
Suppose also the admin interface could be swapped to a Deny mode rather than a Grant mode by scheme, role or globally.
In my use case I'm using forums as the taxonomy being controlled. There is not a way to restrict just a specific forum and leave everything else open while allowing new forums to be open. Now all new forums must be explicitly called out as public.