I may be using the module wrong, I'm trying to grant certain users view access on certain nodes. At this point, I'm just trying to get the initial insert done first, I will worry about update and delete later.

Here's my work flow.

function node_user_access_node_insert($node) {
  //create an ACL
  // acl_create_acl($module, $name = NULL, $number = NULL)
  $acl_id = acl_create_acl("node_user_access",  "view_".$node->nid, NULL);
  
// add entries for each checked account.
    foreach($node->node_user_access['users']['accounts'] as $uid){
      if($uid){
        //add user to ACL 
        acl_add_user($acl_id, $uid);
        
      }     
    }//foreach
    // add ACL to node
    //acl_node_add_acl($nid,     $acl_id, $view,  $update,  $delete,  $priority = 0)
    acl_node_add_acl($node->nid, $acl_id, 1,      0,        0,        0);
    
    
} //node_user_access_node_insert

Everything in SQL tables: acl, acl_user, and acl_node are populated correctly

BUT!!!

In node_access.gid == 0
and node_access.realm == all

where they should be, in this test case

In node_access.gid == 28 //the proper acl_id
and node_access.realm == acl

see attached image for further example.

If I change the values manually, all is well. But, after extensive looking I'm not sure where this is table is populated through the acl module. Any help is highly appreciated!!

Comments

salvis’s picture

Category: bug » support

Please follow the directions on http://drupal.org/node/add/project-issue/acl and report what DNA says.

ACL will supply the node_access records when its hook_node_access_records() is being called as a result of you saving the node.

snovak’s picture

StatusFileSize
new226.43 KB

Sorry I didn't realize there was a protocol. I have followed the steps outlined this time, to the best of my ability. Please see the screen shot, along with the snippet above, I hope you can see where my fault may be. I'm not sure if the process that I use above is the correct ACL workflow. Or perhaps I'm not calling a function that needs to be called. I just looked at your functions and made a logical assumption. If I am at fault more than ACL, please enlighten me as to a source of instruction that might guide me. Thank you!

snovak’s picture

StatusFileSize
new63.87 KB

Additionally, I did check the contents of the $grant array in acl_node_access_records on line 248 of acl.module. All looks good there, I think. Another screen shot attached.

I want to say this is user fault on my end, but I don't know where I err.

snovak’s picture

Status: Active » Fixed

I found my problem. I didn't implement a hook_enabled() function in my module. I didn't realize it was necessary and used to qualify module_invoke portion of the acl_node_access_records function in acl.module. Once, I added it, all is well. It's a little non-obvious, but it's definitely not a bug.. Sorry about that.

snovak’s picture

Status: Fixed » Closed (works as designed)

Just changing status.. ACL works as designed. But, API documentation would help a lot. Great module otherwise!

salvis’s picture

Thank you for the follow-ups!

How would you have liked to have this documented?

Please don't try to manually edit the {node_access} table (as indicated on your screenshot). When you rebuild permissions (for example because you add or remove a node access module, or you perform some operation on many nodes), all manual updates will be gone.

snovak’s picture

How would you have liked to have this documented?

A public document with a short workflow would suffice. It might outline the modules critical functions, how to invoke them and in what order. And, a note that hook_enabled is a required function for a contributing module. I may be describing a very small scope of the overall functionality of your module's capabilities. But, it would be helpful nonetheless.

salvis’s picture

Maybe in README.txt?

Since you've just been through this and know first-hand what would have helped you, would you take a first stab at it?

sutharsan’s picture

Title: Bug writing to node_access table? » Document hook_enabled
Version: 7.x-1.0-beta3 » 7.x-1.x-dev
Component: Code » Documentation
Category: Support request » Bug report
Priority: Normal » Critical
Status: Closed (works as designed) » Needs review
StatusFileSize
new792 bytes

Although 7 years old and Drupal 7, people still run into this. I just did. Patch attached.

For what it is worth, I set the priority to Critical. The module is not usable if hook_enabled() is not implemented, and this hook is not in the documentation.

salvis’s picture

Priority: Critical » Normal
Status: Needs review » Needs work

Well, if an issue pops up once every seven years, it can hardly be called critical. :-)

But I agree that it should be documented, and I like your patch, except for a small nit:

+++ b/acl.api.php
@@ -15,3 +15,24 @@ function hook_acl_explain($acl_id, $name, $number, $users = NULL) {
+ * Inform ACL module that the module is enabled.

I would like this to read "Inform the ACL module that the client module is enabled."

  • salvis committed e536f04 on 8.x-1.x
    Issue #1147226 by Sutharsan: Document hook_enabled().
    

  • salvis committed 425a3a7 on 7.x-1.x
    Issue #1147226 by Sutharsan: Document hook_enabled().
    
salvis’s picture

Title: Document hook_enabled » Document hook_enabled()
Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Needs work » Fixed

Thank you Sutharsan and snovak!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.