list users with access to a node

I would like this as well.

This was originally a request for the TAC lite module. But because access to a node is not determinied strictly by any one module, I thought it belonged somewhere else.

Also, the code involved in showing this is very inefficient. Noone should enable this new block on a site with very many users. It's for developement purposes only, not for live sites.

Anyway here it is. A new block provided by the devel_node_access module. It shows all users and whether they can view, update or delete a given node. This should be useful to anyone developing an access control module, or administrators confirming that permissions are set up correctly.

(Sorry, just noticed the original request was for drupal 4.7. You could try to apply this patch to that version of devel_node_access but YMMV.)
To use, enable devel_node_access, then enable the "by User" block. Put it in the page footer as the table may be too wide for a sidebar. This block is disabled by default as it will use up a lot of resources every time it is displayed.

when selecting users, take the fifty most recently seen (ther eis a column in users table for that). also, use db_query_range() instead of LIMIT for pgsql compatibility

I haven't needed this in a long time, until today. So a year and a half later, I'm following your good advice and I've updated the patch.

Thank you for your patch — that looks very interesting.

I recently contributed a major extension to DNA and moshe asked me to maintain DNA (see #241060: Provide the gory details of node access).

What revision did you base your patch on? The current head is revision 1.15 (and it doesn't have my patch yet), but your patch won't apply. This may be caused by your patch having tabs rather than spaces, but I'm not sure.

(There's talk about rewriting the node access system from scratch for D7, so DNA will probably not apply anymore and I'm changing the version down to 6.x-1.x-dev.)

Changing the global $user object is hacky, as you noted in your comment, and it's also dangerous. The proper way to do it is to call session_save_session(FALSE) before the change and session_save_session(TRUE) after restoring it (see http://drupal.org/node/218104).

My patch was against DRUPAL-5. I know I'm behind the times, but that's the site I'm working on. I'll try to update it for 6, when I can.

Is that '"rewrite node access from scratch" discussion online somewhere?. All node access people should read the case study at http://groups.drupal.org/node/10231. These guys built an awesome access control system but they claim it can't be done with node access (and i believe it). We really need to make it possible to do what they did and still stay within the node access system.

@Dave: Ah, I see. Moshe committed an almost-ready version of my patch to DRUPAL-5, and your patch won't apply there anymore either. I'll sort it out in the next few days...

@moshe: No, it's just that merlinofchaos has mentioned it a few times.

Monster menu is very interesting. Rearranging the content into a hierarchical structure would open up new possibilities, but it's a radical change. Managing such a structure in parallel with the existing flat structure, just for the sake of access control, is not practical.

Right now I'm more worried about the existing node access core bugs in D5 and D6 (D6 is completely crippled!) than about plans for D7...

what are the existing node access bugs?

See http://drupal.org/project/forum_access and http://drupal.org/project/acl. Two bugs apply to both modules, four bugs total.

EDIT: I shouldn't say "apply to" — they're all core bugs that apply to all node access modules, but the symptoms are more visible for some than for others (e.g. FA doesn't care about Event).

Committed to the D5 branch.

thanks salvis ... in the future, let's commit to 6 first, and then 5. that way, we don't surprise users when they upgrade.

Ok, makes sense.

Committed to HEAD, too. Thanks, Dave.

Thanks to you both.

(off topic)
Salvis, you seem to be as expert as anyone on Drupal's node_access. I've dabbled, but its not my core thing. I think these two patches could use your opinion, if you have a moment...
http://drupal.org/node/196922
http://drupal.org/node/249276

(off topic)
I replied to the short one, but I'm not sure the long one is worth getting into. NA is too slow and doesn't scale well as it is, and any attempt to add even more logic / processing / storage overhead is very unlikely to be accepted. On the contrary, there's a desire to redesign NA from scratch in a more scalable way, and if this would materialize, it would change everything anyway.

Yeah, I'm the only one who's had anything critical to say about that patch. And my criticisms have simply been dismissed.

I replied to your comment on the other thread. Thanks for taking a look.