Page Description (for multiple pages with the same title)

Yeah.. this is a real problem with the pulldown for picking parent (apart from the potential scalability issues). I'm going to have to find a better solution for this. I'll post to this issue when I come up with something that works better.

Thanks for the feedback
Ronan

The latest dev has hierarchical parent selectors. This should make it a lot easier to figure out which is which.

Let me know if it works for you and if you have any problems with this version.

That's not good. I'll try to get that taken care of asap or at least revert back to the last version before the end of the day.

r

I've rolled back the changes, so grab the latest snapshot as soon as it's available. Sorry about that.

I've added my changes to this thread as a patch so if anybody has some time to test it out and let me know if they can reproduce the bug mentioned in #3 above I'd really appreciate it. This is a feature I'd really like to get into version 1 of this module.

thanks

I can verify that I see the same problem as #3--the super admin account can still see all the nodes in the parent dropdown, but no other roles can, no matter their permissions.

I can verify that I see the same problem as #3--the super admin account can still see all the nodes in the parent dropdown, but no other roles can, no matter their permissions.

Is this with the above patch applied or a clean install of the module?

On a clean install, the dropdown shows up fine, with all the nodes listed--but without any indication of where in the hierarchy a given node is. Once patched, the dropdown shows up fine for the super admin account, with the hierarchical notation, but is empty (except for "-- NONE --") for all other users who should have access to it.

Great, thanks for helping test the patch, i'll see if I can find a fix for this as soon as I can

Thanks--I appreciate it greatly.

I did a little digging today, and while I'm not entirely familiar with how everything is interacting, I'm pretty certain that the issue is the changed SQL call--in the patch, you "SELECT h.nid, n.title", and without the patch, you "SELECT *". When only pulling the nids, the return value for node_access( 'update', $hierarchylist ) is null, so the items are never entered into the array to build the select list from.

On my test install, changing the SQL call back to SELECT * seemed to fix the problem. Thing is, my return values ended up not being 0/1 or true/false, or even null/1, but null, 1, or 2. Here's where my total ignorance starts kicking in--there's only two places in node_access where it's not directly returning true or false, and that's when it's returning $access or (db_result($result)). And I don't really understand what it's calling or why in those cases.

Anyway, the short version is that changing the SQL call seems to fix it, but might have other unintended consequences. Someone with more familiarity with Drupal could probably help answer that question.

Thanks,

Isaac

That seems to work, thanks for finding that. The reason this is needed is that node_access requires a few other pieces of info (such as author's ID and status) in order to function. I forgot about that when I wrote this new code and neglected to test it with non-user 1 users. (I really need to write automated testing for this module).

As to why node_access returns positive integers in some cases, is due to the fact that the sql it uses to check for grants in the db, is counting the existing grants and simply returning the result. If there are 1 or more grants for the given user for the given node, then the user is considered to have access to that node.

I have rolled a new patch with your changes and will apply the patch to HEAD and maybe even the 1.x branches if it checks out.

Thanks again for the fix

Glad I could help, and thanks for the info on how the grants return value worked. I've applied the patch and will keep an eye out for any other issues.

This patch has been committed to 5.x.1.x-dev.