Private checked on all nodes (but not active)
txcrew - June 18, 2008 - 15:46
| Project: | Coherent Access |
| Version: | 5.x-1.0 |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Greetings,
Upon installation of this module and enabling for a specific content type, I went into a node of that type to edit the 'Shared Editing' fieldset and noticed that the 'Private' checkbox was ticked, without ever ticking it myself. The node in fact was still 'public' and would stay that way until I hit submit with the 'Private' checkbox active. However, if I unchecked private and hit submit, the changes would stick and it would stay 'public'.
When I create a new node, the 'Private' checkbox is not active, as per my settings in the config.
Not a critical bug, but annoying if you have a lot of previously created nodes.
txcrew
#1
This also happens whenever permissions get rebuilt (e.g., whenever a node access module is enabled/disabled). The default seems to set access to private in such cases. Maybe the default should be public?
#2
This was caused by some sloppy logic, can you take a look at 5.x-1.x-dev release and see if this resolves the problem?
#3
I'll take a peek this weekend and get back to you.
#4
It appears that the new code in question is lines 412-429. Right? I'm using the Drupal 6 port, so I replaced the corresponding code there with the new code.
I'm still having the problem after rebuilding permissions. Some nodes suddenly become private although I've explicitly marked them as non-private in the shared editing form. It looks like only the nodes that were added after module installation/previous permissions rebuild show up as non-private. Everything else seems to revert back to private despite the non-private setting. Weird.
Can we add a button on the coherent access settings page that allows us to make all existing nodes public unless they have been explicitly marked as private? Then when this problem comes up after a permissions rebuild (or bulk data migration from another site) we can go there and handle it in all at once rather than one node at a time.
#5
When I first installed this module on Drupal 5, it made all the nodes it affected private. However, the fix in 5.x-1.x-dev, followed by a rebuild of node permissions, did the trick, and it seems to be working as expected.
Except for that checkbox. If I set a node to be Private, it is set to be private, but when I go back to edit the node, the checkbox is still cleared. I'll see about writing a patch when I have a bit more time later.
#6
I'm just getting up to speed on how node_access works, but it certainly seems like just using the $grant_view to set the Private checkbox isn't working. I've played with this a bit, and I think the problem is that coherent_access[private] is never going to be set to 1, which is what the checkbox needs to appear checked.
I'm attaching a patch that seems to fix this. I'm flipping the bit when displaying the form, and adding a #return_value that says "when this is checked, return 1". I think the result is that when private is checked, 1 is returned, and when it isn't, 0 is returned. It's working in very limited testing, but more would be a very good idea.
#7
I think I'm just going to fill this issue with my own posts. *sigh*
One more thing I want to mention. I tried rebuilding node permissions after implementing this change, and it seemed to reset the node I was testing on from private to public.
#8
chellman, thanks for the patch it helped narrow down the problem. It was due to some faulty logic in hook_nodeapi()
#9
Automatically closed -- issue fixed for two weeks with no activity.