Node-level access with Taxonomy Access Control

The author of this module has told me by email thathe is no longer supporting the code. If somebody else would like to take over the development of it please contact him.

I too would like this module patched up ready for use.

I am sure there is a valid reason but it is incredible (and sad?) that one of Drupal's most important modules is without a maintainer.

Should we stop using taxonomy in any form then? Because the taxo_access module is what manages permissions.

Here is my latest patched module for the topic:
Access is set by LAST term only!

And see the patched taxonomy.module attached for
- problem editing node with only update access

Taxonomy_access is should not be mixed up by taxonomy module, which is one of the basic strength of drupal.
Altough TAC module is quite useful, there is no plan to change the drupal core toward taxonomy-based access instead of node-based access.

Although i tried to test it a lot, please test the patched modules, and I await your comments about it. :)
It would be nice to finally make it to be a stable module.

Please let us know about your or ANYONE's testing result.
I tested mainly for "view" access rights, and I did not have time to test it for "creating, updating" rights since it is not required on my site at the moment.

It would be useful to make a BUG OR REQUEST list, how the "creating, updating" rights should work.

As i see now the function to map the "node_access" table based on the TAC module's "term_access" table works fine. (Although it might need some optimization since in case of a site with thousands of nodes it can be slow).

So any idea (and programming) is welcome.
I wrote to the author of this module to take over the support, since he has no time. But it might take some time.

Thanks, Keve, for taking over the maintenance of this module. I consider this module crucial to drupal (at least until they implement node-level permissions).

As for how the rights should work, here goes...

Basically, each permission (view, create, update, and delete) should be independent of the other permissions. Setting one specific permission doesn't imply that another permission is given. Specifically:

CREATE

a user with this privilege should be able to create content with this taxonomy. Once it's been created, this permission does NOT give the user the ability to view or update or delete that content.

UPDATE

a user with this privilege should be able to update content with this taxonomy. This permission does NOT give the user the ability to create or view or delete that content.

DELETE

a user with this privilege should be able to delete content with this taxonomy. This permission does NOT give the user the ability to create or view or update that content.

VIEW

a user with this privilege should be able to view content with this taxonomy. This permission does NOT give the user the ability to create or update or delete that content.

(note: without the additional view privilege it may be impossible to update or delete content, but that should be obvious to admins who are setting up the permissions.)

Possible permission scenarios:

I wrote the taxonomy_19.patch file (for fixing the "update only permission" problem). I wanted a way to control how pages were created. So the admin user would create the node and then assign ownership of the node to a user with only update permission.

I can also envision where an admin might want users to be able to create content and never be able to modify or delete that content.

It's also possible that an admin might want to create a censor, a user who only has view and delete privileges.

Hi keve

I wrote to the author of this module to take over the support, since he has no time. But it might take some time.

Did you saw this ? And that ?
Can you also allow to be sent mails ?

Good luck.

I've noted in a couple of places that people refer to taxonomy-based access control being good "until node-based access is available" or inferring that it is not possible with this module.

Part of why I like TAC is that it made it possible to add per-node access control fairly easily.

I created a taxonomy called "Access Control", with terms in it corresponding to my various user roles.
I then added the appropriate node types to the taxonomy (I don't need access control for all my node types).
I then limited which roles have access to each of the terms in that taxonomy.

Now, each node, when created, has a box where the person entering the node can select which roles can view it, and of course they can't select a role they don't have access to.

It's also easy to set it up so that only, say, an admin can _assign_ a certain permission - any category the user doesn't have create/edit privileges for won't show up in their selectable list.

Now that there's the patch that makes sure that privileges are assigned by all the categories to which a node belongs (instead of just the last one), it seems to work pretty well.

I'm not sure whether the permission checking process is faster or slower or more or less efficient than node_access_byrole, but the functionality seems to be roughly duplicated, and it works for me.

Basically, I have a taxonomy set up that controls access - and the permissions in the "Category Permissions" setting control not only who can see what, but who can assign which permissions to a piece of content.

I suspect that if one controls access through a single taxonomy, that it requires less checking than if each individual taxonomy category/term must have its permissions checked.

Anyway, my point is that with very little fiddling, and no changes to TAC (unless there's a bug I haven't noticed), you can get node-level access using TAC.

I already commited these patches to current taxonomy_access.module couple of months ago.