Ajax for 'devel node access by user' block

this patch has the correct access setting on the callback

(I did change the name of this file after I uploaded, but it didn't seem to take)

1. Where do those errors come from? I've never seen them. We need to fix them! Please open a new issue for them.

The problem is caused by the node access module that is being developed. This patch enabled me to pinpoint which cases (which users, and which grant operations) are causing the problems so I could investigate further.

2. It's a very interesting concept. This block does cause considerable overhead, which is why it's turned off by default. I'm sure that filling it asynchronously gives you a faster page load, but you're turning 40 (or rather 80) grant evaluations into 40 Drupal bootstraps (plus 2 grant evaluations each). Do you have a feeling for what that does to the server load? Especially on a development machine running under a debugger? I turned the block off by default for performance concerns, but I never actually found a noticeable difference.

No, I admit I have no appreciation for what this does to server load. I figure if you're developing a site and using Devel node access then you're in an environment where you might not particularly care about this because you have no real users and visitors. It still only does one request at a time, firing them off as the previous response comes in, or if there is no valid response in 3 seconds (that's an arbitrary time - jquery versions before 1.5 unfortunately don't have an ajax on-failure handler).

3. I think this should be turned off by default for the same reasons.

Fair enough, I kind of went back and forth on this one, and left it on because at least then the page loaded properly in the problem scenario, I liked the way it worked and enjoyed watching the grants appear. I also worry people wouldn't be aware of this feature if they were in a situation where they'd need it.

4. Patches always need to go against the latest branch (D7 at present) first. Nevertheless, we can investigate the merits of this idea under D6 now, but I won't commit it to D6 before D7.

No problem. I developed it in 6 for what I needed and as a proof of concept / proposal at this stage. Happy to work towards a 7.x patch, perhaps after some more discussion.

I need some time to get up to speed with Git (just got a book from Amazon) before I look at this, and I'd like to get some third-party opinions on this.

You know I spent hours yesterday reading about Git, feeling like I couldn't find the information I was looking for, and then realised there is an incredibly handy guide at the 'Git instructions' tab on the project page of the project you want to work with. Coupled with the 'git access' tab when you edit your user profile, you can do routine patches/commits on projects while you're still learning the finer points of git.

I'm less concerned about running on a live site (you're not supposed to do that), but about running under a debugger. First, performance-wise, and second, getting additional requests every 3 seconds makes this completely unusable if you set breakpoints and do single stepping.

I suppose that would be the case. You would be better off with the original block, and probably wouldn't benefit as much from this if you've got tools that can step through the code.

You are off-loading the Core and DNA evaluation into one and the same request, right?

I believe so, the callback calls _devel_node_access_explain_access() which does both?

I'll look into the policies you've mentioned.

I wonder whether the checkbox should be where you put it, or in the block configuration (like the 'Switch User' settings)...

I think you should make the call on this one. It doesn't bother me either way, but I think we have a few options:

- On the devel settings page (perhaps 'devel node access' should have it's own fieldset so we don't have to prefix each DNA config with 'Devel Node Access')

- On the block configuration page. Makes logical sense, but people may not think to look there, I even managed to miss the 'switch user' settings the first time I went looking for them after you mentioned it. The 'debug mode' setting also seems to apply specifically to the blocks (?), but that is on the config page.

- On the block itself as a link below the block content, which would switch the setting much like switching between users in the 'switch users' block. This seems the most accessible, but the least 'config'-like option and requires more work/code to implement.

- On the block configuration page, but with a link under the block similar to the 'debug mode' link.

Just some thoughts to consider, I can do it anywhere really.

I could also use some feedback on the text in the configuration setting:

[ * ] Devel Node Access by User Ajax
_{Use Ajax to populate the Devel Node Access by User block. This loads the initial page faster, and uses dynamic calls to build the data in the table, one request at a time. JavaScript must be enabled in your browser.}

I still want to say 'Ajax' to paint a clear/correct picture for those users that do understand what it means, but as well mention JavaScript as you said. The #title is also a bit awkward.
This text might have to change to suit the context of where the setting ultimately appears.

Here is a Drupal 7 git patch for consideration.

woops, I only changed the default in the config, not where it's used.

You have to rebuild your menu cache to enable the callback (which would normally happen when the module is installed) Hmm actually that doesn't apply to Drupal 7. Will investigate.

sorry about the massive delay on this issue, my ISP isn't providing a working internet connection at home, meaning I pretty much just play solitaire now :(

I've recreated the patch against a fresh git clone of 7.x-1.x, including the variable defaulting to FALSE in both places.
I haven't had any problems like you did with it not working at all, so I don't know what happened there - there is in fact a change in hook_menu, so the menu would need to be rebuilt to be sure.
Please review.

I've forgotten how to include the .js file in the patch :(

OK This one includes the .js file.

Just noticed a couple typos

Ah oops, looks like I put the menu item inside an existing if statement <?php if (!module_exists('devel')) { ?>
I'll get this fixed up soon.

Here it is again with the menu in the right spot.

Here it is again with the menu in the right spot.

I just realised the newest patch is missing the javascript part :( This is driving me crazy :/
I'm so sorry about this.

Rawr, I have rerolled a new patch and retested it. There is a weird thing in the latest dev where the half the dna module file appears commented out, so I've had to change that...