"All" option per vocab for by default access to All terms (and new ones automatically).

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.

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/.

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;

Subscribing. Interested in this for Drupal 6. Would be a real time saver.

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?

subscribing

subscribing

I'm going to take a crack at this.

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.

Subbed. Using Tim's workaround in #9 above, but I'd prefer to be using a flat vocabulary rather than hierarchical.

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.

Attached is a patch to add the "all" option to both role-based and user-based access settings. The patch handles SQL rewriting and the node access system.

I'd like to hear what others think of that patch because I'm on the fence about it. This seems to be a fairly requested feature (even though I suspect it is not needed, if you choose your tac_lite schemes wisely). The patch introduces a convention into tac_lite that a negative term id is not a term id, but a negative vocab id instead. That part is either inspired and elegant, or an ugly hack. On first glance I'm not sure which!

Other thoughts...

The patch removes a bunch of code from tac_lite_admin_scheme_form(). Why?

The patch makes a query, "SELECT tid FROM {taxonomy_term_data} WHERE vid = :vid AND tid NOT IN (:tids)" which seems like pretty intimate knowledge of how the taxonomy module stores its data. Can that be replaced by a public API call, maybe taxonomy_get_tree()?

This "negative tid is a vid" convention might affect the contrib module tac_lite_create. I'm not sure, I haven't actually tried this patch yet, just looking it over.

"The patch removes a bunch of code from tac_lite_admin_scheme_form(). Why?"

The removed code seemed to be an old duplicate of the function _tac_lite_term_select(). I did my best to check that the removed fragment had no side-effect.

"The patch makes a query, "SELECT tid FROM {taxonomy_term_data} WHERE vid = :vid AND tid NOT IN (:tids)" which seems like pretty intimate knowledge of how the taxonomy module stores its data. Can that be replaced by a public API call, maybe taxonomy_get_tree()?"

I considered using taxonomy_get_tree() but it is an expensive function whereas what we need here is just plain tids. I could not find an API to get a plain list of taxonomy tids. The data structure of taxonomy has been stable for a number of core versions, so I didn't feel particularly bothered (as a module maintainer) about accessing the tables directly.

"This "negative tid is a vid" convention might affect the contrib module tac_lite_create. I'm not sure, I haven't actually tried this patch yet, just looking it over."

That's right, I didn't test tac_lite_create.

"This seems to be a fairly requested feature (even though I suspect it is not needed, if you choose your tac_lite schemes wisely)."

If you can offer a recipe to allow certain roles to gain access to all future terms of a vocabulary, I'll use it gladly!

"The patch introduces a convention into tac_lite that a negative term id is not a term id, but a negative vocab id instead. That part is either inspired and elegant, or an ugly hack."

I just used the idea of a previous commenter. If you don't like it, I'm sure we could find an alternate approach to store the "all" option.

Ah, yeah that was suggested... years ago! Forgive me for forgetting.

> If you can offer a recipe to allow certain roles to gain access to all future terms of a vocabulary, I'll use it gladly!

How about a new vocab called privacy with a few terms like "administrators", "editors" etc. Tag the nodes in question with terms from both vocabs. Not exactly the same thing, but possibly even clearer to an administrator what's going on.

I do plan to give this patch a try when I have a moment (haven't yet). I do appreciate you submitting it.

Thank you for contribution. 👍
Drupal 7 is no longer supported. 🤷‍♂️
Closing as outdated. 🔐