This is a patch for taxonomy.module that adds taxonomy based access control. Basically it creates a table called taxonomy_access to store the term id, the role id and permissions. Then, it implements taxonomy_node_grants which returns a list of terms this user's roles have permission to perform the operation, then node_access looks up a corresponding entry in node_access and determines whether or not the user has access.

Next on my todo list is adding permission altering functions that keep the node_access and taxonomy_access tables synced when altering taxonomy permissions, as each taxonomy_access entry needs a corresponding node_access entry with realm='taxonomy', the gid=tid and the nid=0, with the proper permissions. Then a GUI to allow you to edit the permissions through the administration menu.

CommentFileSizeAuthor
#12 taxonomy_access.patch1.48 KBpyromanfo
#11 taxonomy_access.module10.08 KBpyromanfo
#6 term_access.mysql542 bytespyromanfo
#5 term_access.patch11.95 KBpyromanfo
#2 term_access.tar.gz1.41 KBpyromanfo
taxonomy_access.tar.gz832 bytespyromanfo

Comments

pyromanfo’s picture

pyromanfo commented

This should be against CVS, my bad.

pyromanfo’s picture

pyromanfo commented
StatusFileSize
new term_access.tar.gz1.41 KB

I just updated it to do three things

1) remove debug text, whoops
2) change the db table to term_access to follow the naming convention of the rest of taxonomy.module
3) added 3 functions for adding, deleting and updating taxonomy permissions which keep track of entries in node_access as well as term_access

This only patches taxonomy.module and adds a db table.

Does anyone else think it'd be a good to add these functions to the node_access stuff as well?

Also, next up is a GUI to edit these permissions in user.module

Bèr Kessels’s picture

Bèr Kessels commented

Hi pyromanfo,

Just a few smaal things I learned on drupal.org. drupal developers use the -u flag when patching (unified), this makes the patches much better readable.
The other thing is the use of tgz. preferably patches are committed in plain text. That way its much easier to review. Another really minor thing is your use of tabs. In all drupal code two spaces, instead of tabs are used. I saw you have a couple of tabs and a couple of spaces.

But all in all I think this patch can be usefull indeed.

dries’s picture

dries commented

Thanks pyromanfo. I haven't looked at the patch yet. I just wanted to point out that I'm not going to include a permission scheme in the Drupal 4.5.0 distribution yet. It might be a good candidate for inclusion in Drupal 4.6.0 -- time will tell. In the mean time, this is best maintained in the contributions repository. I suggest you check with JonBob first.

pyromanfo’s picture

pyromanfo commented
StatusFileSize
new term_access.patch11.95 KB

Thanks Ber, I fixed the whitespace and the diff format.

Dries, how do I contact JonBob? I can't send PMs and I can't find his email anywhere, even on his website.

Here is the latest patch, which patches taxonomy.module and user.module. No database changes this time. There's a nice GUI under admin/user/configure/category that will let you set permissions for each user role, including default category permissions. Also, there's a "Default" page where you can set default category permissions for all the roles.

pyromanfo’s picture

pyromanfo commented
StatusFileSize
new term_access.mysql542 bytes

And here is the term_access.mysql file, for reference.

pyromanfo’s picture

pyromanfo commented

Oh yeah, this keeps all entries in node_access with full permissions, because node_access doesn't keep track of user roles like term_access. Therefore there could be several rules for different roles against the same taxonomy and in the node_access table the permissions of the last role updated would be the only one to exist, so I just bypass the node_access table entirely. Doesn't it sorta make it redundant to check the node_access table when hook_node_grants is already doing it's own checking? That is the point of hook_node_grants, right?

Also, are these replies always supposed to show up on the mailing list? Or is setting it to postponed keeping that from happening?

jonbob’s picture

jonbob commented

"Dries, how do I contact JonBob? I can't send PMs and I can't find his email anywhere, even on his website."

The devel list (or maybe IRC) is my preferred mode of communication.

"Also, are these replies always supposed to show up on the mailing list? Or is setting it to postponed keeping that from happening?"

Only items set as "patch" get sent to the devel list. Many developers (like me) subscribe to e-mail notifications on all issue types, though.

I agree that this should be started as a contrib module. There is a term-based access module in my sandbox you could look at, if you haven't already. The thing it does not handle is removing terms from listings (like forum indices) if the user does not have view permissions for a term. Your patch doesn't appear to handles this yet either, but I have not yet had time to look at it thoroughly. That's the only issue I think could not be solved entirely by a contrib module.

pyromanfo’s picture

pyromanfo commented

Ok, I'll start up a contrib module later tonight, however are you suggesting I make it a .module file or merely stick the patches in the contrib module directory? Because I can make it a seperate .module file, it would just mean the configuration GUI would be off in a strange place, instead of where it is now in the user configuration.

Patching the node view was next on my list. Really it's just a matter of calling node_access before putting a node in the view list, shouldn't it be doing that now? I mean, should it be a bugfix for the current version, or part of the contrib module?

jonbob’s picture

jonbob commented

I'm suggesting a .module file. Modules can inject pages anywhere in the menu structure, so there's nothing stopping you from adding a page at /admin/user/whatever for configuration.

I'm not sure what you mean by "patching the node view." Reread carefully what I wrote: I'm talking about removing *terms* from *term listings*, not *nodes* from *node listings*. The latter is already handled quite well.

pyromanfo’s picture

pyromanfo commented
StatusFileSize
new taxonomy_access.module10.08 KB

I'm not sure what you mean by "patching the node view." Reread carefully what I wrote: I'm talking about removing *terms* from *term listings*, not *nodes* from *node listings*. The latter is already handled quite well.

Ok I found out what that was, I was merely misinterpreting the role of node_access in all of this, I fixed that. It's also it's own module now, just waiting on CVS access to make a module in the contributions repository. In the meantime here's the seperate module file, for easier testing.

pyromanfo’s picture

pyromanfo commented
StatusFileSize
new taxonomy_access.patch1.48 KB

And here is the patch to taxonomy.module to take care of the other problem you pointed out. Now it trims the terms selected to only those the user is authorized to view, and gives the access denied error if none are left.

joshuajabbour’s picture

joshuajabbour commented

Beautiful! I love it. just what I needed.

My only request now is to add an option to have perms per vocabulary. Maybe the best way to do this would be with some javascript. When you check a checkbox next to the vocab name, it automatically selects all checkboxes for all terms in that vocab. Maybe I'll see what I can come up with...

And what happened, did you ever get CVS access to make a new contribution? This should be put up there.

p.s. The taxonomy.module patch doesn't seem to work. It applies (not cleanly), but doesn't prevent taxonomy terms from being displayed.

p.p.s. Huge TIP for anyone out there trying to use this. You must reset the default node permission in "node_access" table in your database. It is by default set up to let anyone view any nodes (hence the '1' for 'grant_view' in the 'all' realm). That '1' needs to become a '0' in order for this module to work (IF you are setting up view permissions. If you are keeping view permissions for everyone, it doesn't matter. But if you set it to '0', you must add view permissions for every term and every role you want to have view permissions...)

joshuajabbour’s picture

joshuajabbour commented
Project: Drupal core » Taxonomy Access Control
Component: taxonomy.module » Code

reassigning to correct project.

pyromanfo’s picture

pyromanfo commented

wazdog, from my tests with a fresh 4.5.0 install you don't have to do that. Simply go into "Default" and remove all permissions, then set the permissions for the user role accordingly and they won't be able to access anything.

joshuajabbour’s picture

joshuajabbour commented

That's not my experience, but I was using the older version posted here, with the taxonomy.module patch that didn't work. I'll try it all again with a fresh install and the new project you just uploaded to cvs.

Thanks again, this is a wonderful module. I was dreading writing this over the weekend, until I stumble across this thread... ;)

sulleleven’s picture

sulleleven commented

hey.
Today I have been looking into best way to create access control to 'groups'. I started with this module and will be looking more closely at the jonbob's node level access modules as well.

I installed this taxonomy mod and here are a few things I am noticing. It works, however:

- When user creates content, they are able to post into categories that they do not have permission to read/write/edit.
This is what appears when I post to a category that I do not have access to:

"Your forum topic was created."
"You are not authorized to access this page."

So, two things should be reviewed. One is to filter the list of categories to only display those that the user has access to and the other would be to block a user from adding content to a category that they do not have access to.

- This other issue may be something that the new block access module can handle.... but i don't think that users should see categories (that they have no access to) listed in category block or any other block that displays any data at all from a category that user does not have access to.

I am not suggesting that these issues should be resolved strictly within this module, but regardless, these are some thoughts and observations.

I also am trying to figure out how best to create groups/clubs in drupal so that members of such groups can have their own group nodes (forums, blog, files etc). Maybe i need to look at this from a sub-node perspective. Meaning, each node can have a sub-node that is meant to be binded to a specific category which is binded to a specific role. Or, maybe flexinode could use the function of adding content type nodes to specific roles. Still trying to conceptualize which is best approach... and I have read alot of drupal notes on all this stuff... including jonbob's latest work.

babble_out

pyromanfo’s picture

pyromanfo commented

Please look at the taxonomy.patch in both CVS and the 4.5.0 version. This patch to taxonomy.module handles everything you're talking about well, from what I can see.

sulleleven’s picture

sulleleven commented

howso?
i just used the patch from http://cvs.drupal.org/viewcvs/contributions/modules/taxonomy_access/taxo...
and here are results:
patching file taxonomy.module
Hunk #1 FAILED at 106.
Hunk #2 succeeded at 418 (offset -18 lines).
Hunk #3 succeeded at 433 (offset -18 lines).
Hunk #4 succeeded at 451 (offset -18 lines).
Hunk #5 succeeded at 470 (offset -18 lines).
Hunk #6 succeeded at 494 (offset -18 lines).
Hunk #7 succeeded at 514 (offset -18 lines).
Hunk #8 succeeded at 554 (offset -18 lines).
Hunk #9 succeeded at 594 (offset -18 lines).
Hunk #10 succeeded at 683 (offset -18 lines).
Hunk #11 succeeded at 730 (offset -18 lines).
Hunk #12 succeeded at 750 (offset -18 lines).
Hunk #13 succeeded at 918 (offset -18 lines).
1 out of 13 hunks FAILED -- saving rejects to file taxonomy.module.rej

Nothing seems to have changed... at least not that i can tell. I still can post into categories i do not have access to.
hunk 1 failed....

pyromanfo’s picture

pyromanfo commented

did you patch against the 4.5.0 version of taxonomy.module? I see a hunk failed, with my local patched version of taxonomy.module I cannot see forums or posts from forums I do not have view access to. Are you using the latest taxonomy_access.module from CVS? You may need to update to this, and enable the new module under "administer>>settings>>taxonomy_access" to remove the default "view all" permission.

Anonymous’s picture

(not verified) commented

it is working now. i had to remove the permissions from the 'default' role...
i am using the cvs version of your patch... the second time I ran the patch on my 4.5 taxonomy.module, no errors. To be clear... this patch is for 4.5 taxonomy.module, right? Or cvs?

I am willing to create some addons for this such as blocks and templates to provide the controlled display of permitted data to user.

nice work!

sulleleven’s picture

sulleleven commented

pyro-
i started a fresh cvs drupal install and again tried out this module (cvs version). maybe i should just wait for the merged updated version?

to be clear- the taxonomy.patch is only meant for 4.5 version of taxonomy.module or cvs?
will this taxonomy_access.module from cvs work with drupal cvs ?

right now, i am back to where the access control works except for when creating content as all categories are selectable to post into by users who should not have access.
I had problem with patching taxonomy.

thanks for any clarification.

sull

pyromanfo’s picture

pyromanfo commented

Yes the new updated version should take care of you. taxonomy.patch is for 4.5.1 of taxonomy.module.

Anonymous’s picture

(not verified) commented