I had tested Workflow module on my D5.2 site. Workflow is great but it didn't accomplish what I expected. After disabling and uninstalling Workflow I got "access denied" for the nodes added or updated. Looking up in node_access table I found that the record related to the node is missing.
If I have (for example) a node 345 than in the Drupal default node access policy it must be a record in node_access table with these values:
nid = 345
gid = 0
realm = 'all'
grant_view = 1
grant_update = 0
grant_delete = 0
But this record is missed and I have to add it in order to get my node displayed to other users than #1.
If I add a new node than the node_access record is not added. If I update an existing node than the related record from node_access is deleted.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | workflow_access.patch | 979 bytes | imrook |
Comments
Comment #1
emilyf commentedI too am having this very critical problem. I had workflow module from 4.7 and upgraded to 5 when my site upgraded. Now I don't need workflow anymore, so I went to uninstall workflow_access. The site hangs on the page and eventually times out. workflow_access is still enabled when i refresh the page. however, any user role other than admin can no longer see any page on the site even though they have 'access content' permission. they get 'access denied' on every page. This is such a critical problem, I am a little surprised that this issue hasn't been touched in 10 months...especially since the readme says "You can safely disable the Workflow Access module. Any nodes that were under
access control before will be reset to being viewable by everyone, but editable
only to users with the "Administer nodes" permission."
When this happens, the only thing I can do is revert my db to before disabling this module. Is there a query that can fix the node_access table or do I have to leave this module enabled forever on? The query on this page http://drupal.org/node/64114 does not really seem like an option to me since I do have OG up and running and I assume rebuilding that table will trash OG's node permissions.
Any suggestions on how to resolve this? I'm stumped.
Comment #2
Leeteq commentedI guess you have resolved this already, but for other readers, and since this case is still open: Did you have to do that step and rebuild the permissions? If so, which steps were required? Did you get into trouble regarding OG, for example related to how to get old content "back in place"?
Anyone with experience regarding this that could outline the correct order of steps?
This seems like a scary bug that would keep users from getting started with this module until this issue is resolved.
Comment #3
emilyf commented@DanielTheViking
FYI, this was really a disaster for me. In the end, I was looking to upgrade my site to Drupal 6 anyway, and when I did that, I was able to resolve it. During the upgrade, I had to disable all modules and I finally disabled this as my last module. Keep in mind that really didn't fix anything. After I did the 6 upgrade, I reinstalled OG, and then I had to rebuild node-access table from the administration area. This finally fixed it.
But for Drupal 5, there was never a way that fixed this. Because of this, it is unlikely that I will ever use workflow_access for D6!
Comment #4
imrook commentedI have been bitten by this problem on D6. I did not uninstall the module, however. I'm still using it and getting Access denied errors after editing nodes. I did some tracking down and believe the root cause of this problem lies in the way Drupal core handles node_access grants. I wrote a detailed post about it here. I also noticed there is a similar issue against OG (#213050: Access denied on new content) which may be related. At the very least, it seems like rebuilding permissions should give the same result as editing an existing node, but at current they don't.
Comment #5
imrook commentedSo after some thinking, I realized that workflow_access is at least partly causing this problem. The case where the content type does not belong to a workflow is undefined, which results in no grants by default. I suppose this behavior is by design, but it surprised me and probably others. Attached is a patch which adds a check to see if the content type has a workflow. If no workflow is associated, it grants view permission to the anonymous and authenticated roles. This might be better as a set of configuration options, where the default permissions can be set by role for nodes with no workflow, but I don't have the time to write that patch right now and this one does what I need.
Comment #6
Leeteq commentedThanks, imrook, good to see this moving forward.
I dont recall ATM what exactly is the consequence if:
1. a site is set to NOT give access to content for the anonymous role (content only available to logged-in users)
and
2. then view access for the anonymous role is suddenly granted to nodes affected by this patch...
Will Drupal still block access to any and all content, or will nodes affected by this patch actually become visible to people who are not logged in (and hence robots, search engines, etc.)?
Comment #7
imrook commentedThat's a good thing to check. The node_access() function checks for 'access content' permission before going to the node_access table. So grants by access control modules can never override that core permission.
Comment #8
imrook commentedUpon further investigation, I have found the patch from comment #5 does _not_ work. It incorrectly gives a grant permission for anonymous users to view any content. This prevents other access control modules from having the desired effect. My understanding of the node_access system was incorrect. If no modules exert any access controls, then Drupal core will automagically grant view permission. This was not happening in my case because of another misbehaving access control module. Fixing the offending module fixed the problem. There is only one corner case that I'm aware of now. If a node has grants for the 'workflow_access' realm in the node_access table, but is not associated with a workflow (this can happen if a content type is disassociated with a workflow) A node edit should fix a single node and rebuilding node permissions should fix the entire site in this case. At any rate, I no longer have an issue and the patch from comment #5 should be thown away.
Comment #9
Bastlynn commentedSince this request is over 2 years old, I'm going to assume a solution was found or you've moved on. If not, please get updated to the latest versions of all modules and make a request for it against Drupal 7 and I'll be glad to take a look at it.