Anybody successfully use na_arbitrator, OG, and TAC together yet?

By rubenk on 9 Sep 2006 at 01:44 UTC

Does anybody have information on how I can use na_arbitrator, OG, and TAC in a Drupal 4.7 installation?

My main reason is to hide certain taxonomic categories from certain role types when posting but still allowing them to view items posted with those tags.

Alternatively, if anybody knows of a way I can hide the categories when people post a node type from within an OG group, then that would probably be much cleaner...As it is right now, a person in the group "engineers social group (ESG)" can click post a book from the ESG block and see two categories: one is "activity type" (with a bunch of options) and the other is "classroom media" which is intended for a totally different group to use.

I would limit the categories by making them part of their respective groups but this means that another social group will not have access to the "activity type" category.

Comments

You can't use OG with any

merlinofchaos commented 9 September 2006 at 06:54

You can't use OG with any other access module at this time.

-- Merlin

[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

-- Merlin

[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]

But if you feel experimental

bomarmonk commented 9 September 2006 at 07:27

You might check out the access multi module. It seems to work rather well with taxonomy access and simple access (running at the same time). I haven't tested with organic groups. It might be worth a try. See:

http://www.lab.canfield.com/projects/na_multi

I was very excited to see

rubenk commented 9 September 2006 at 14:42

I was very excited to see that Moshe is working on a patch to make og compatible with na_arbitrator. Yes! now I just have to see if it is compatible with drupal 4.7 and OG 4.7

na_multi

mwu commented 12 September 2006 at 15:39

who is the author of na_multi? The name robb does not sound familiar.

The guy is very helpful

bomarmonk commented 13 September 2006 at 08:02

Robb Canefield. From my experience with this module developer, he is friendly and capable. I'm curious, however, how his module actually compares to the functionality of the node access arbitrator. From what I've heard, they do very different things. Where does the future of Drupal go with access and permissions (I've heard rumors that drupal 5.0 will be more flexible with permissions)? It seems that for Drupal to really function to its full potential, access and permissions needs to become more flexible and user friendly. This is the voice of a user, not someone who can actually make this happen. Sorry.

very different...

Anonymous (not verified) commented 26 September 2006 at 17:47

The two modules are very different. na_arbitrator basically defines an API that node access modules use to write to the database. This takes care of the problem of modules overwritting each other's access or having to include entries for nodes they don't care about. That's it. This is a good thing, but not what many people actually want.

the node multi module instead solves what I call the 'default allow' policy. Drupal queries the database table and determines if access is allowed if one or more access control modules say it's ok. This means that if one module says it's allowed, and another module says it isn't, drupal allows it. Granted this is reasonable, because how in the world does drupal know which module is right?

This makes it completely impossible to, as an example, use taxonomy_access_control to allow all registered users to view pages of a certain term, but then use path access to deny certain roles access to pages of those same terms based on a path. Since one module always grants, there is no way for another module to deny.

Now, what the node multi module does is allow the admin to change the query drupal uses. By default drupal queries the database with something like (in english):

check if module1 allows viewing OR module2 allows viewing

the multi module allows you to change that so it instead queries

check if module1 allows viewing AND module 2 allows viewing

In other words, they both have to agree. You can get much more compliated than that, but that's the idea.

The problem with this, I found, is that the performance of this is not so hot. It sounds simple here, but to actually modify drupal to do that, in a user configurable way, is a MUCH more complicated query. The multi module cause node access queries on my site to go from a < 20 ms to 2-3 seconds. Granted we have a LOT Of nodes and a lot of node access entries...

My solution instead was to modify node.module. Basically all I had it do was to check how many of the modules granted access. For view access, I modified it to require at least 2 modules to agree, since I have two node access modules. This means that if one grants and the other denies, it will be denied, that's the way I want it. For edit and delete, it only requires 1 to grant access, since by default no one can edit anything and only one module has to grant it.

Performance is much better this way, but of course I have a hacked node module...

consider hook_form_alter instead

Dave Cohen commented 26 September 2006 at 17:57

Looking at what you are trying to do, consider writing a hook_form_alter to accomplish it, rather than introduce extra access control modules. You could write your own logic to remove some taxonomy terms from forms, depending on who the user is.