Steven Jones wrote:

Hi,

I think the functionality that you're after could be covered by creative use of hook_node_grants, node_access_grants and your own user access system in OG user roles.

Here is where I bump into my Drupal ignorance. I thought (and please excuse my misuse of terminology) node grants and node permissions were different. By node grants I mean "grant_list", "grant_view", "grant_update", "grant_delete". By node permissions, I mean "create_node_content", "edit_node_content", "administer_module", etc... Now, if it's possible to create a mechanism that adds the correct user access roles within OG, then it sounds like that's the way I should go.

I myself have found much of the OG functionality lacking, and would be interested in helping to write these features if you wanted.

Yes, very interested.

Core modifications are really not needed, but would indeed save a lot of work!

For example, on OG, this is the user_access check to determine whether to display a create content link: node_access('create', $type->type)) node_access, as you know, calls user_access. Theoretically, you are saying that it's possible to create a user access function in OG that would override or append to the Drupal core user access function? -ron

Steven Jones wrote:

Actually having properly looked at node_access, indeed you can't do what you want without changes to core.

That is, in fact, what I am proposing. A hook in user_access or even $user->roles which would allow a module to add roles, thus permissions, to a user in a particular environment -- in my case, within an OG group context.

'create' operations are somewhat special and the only thing that gets to decide if a 'normal' user can create a node is the hook_access defined in the node's module (that is the module that allows the creation of that sort of node.)

In the case I described, that would be node_access. With my modification, node_access is working properly as well. The problem is that somewhere in this process: node/add/<node type>?gids[]=<group nid>, something fails. The only clue I have is that my debug of user_access reveals that the arg(0) context is lost.

Taxonomy Access controls creates by using db_rewrite_sql, but in my mind that is ugly.

Fortunately, the taxonomy access I need is granted by role. So, if user_access / node_access are returning the correct roles, taxonomy works correctly automatically. That has been my experience so far.

If any developers are still following this thread, would adding a invocation of nodeapi or something similar to node_access be permissable, as in this case at least, it would be very useful.

FYI, on a totally separate project, I utilized the Extensible Node Access/Authorisation Capability patch: http://drupal.org/node/122173 which does exactly what you ask above: invokes nodeapi for access. It works beautifully for everything EXCEPT lisitng, which requires node_db_rewrite_sql(). And, it does not deal with user_access permissions. So, even if I got it to return the correct permissions for a node create, I still have to deal with user_access and $user->roles calls elsewhere. The OG module itself does 18 calls to user_access. What I'm saying is that if there were a way to have user_access invoke some sort of _access hook so that other modules could add permissions (or roles) to the ones it already creates, this would solve my problem. EXCEPT that I still can't figure out why the create isn't working by default now.