Edit links do not properly respect access modules in view

Changing to critical, as this completely undermines any use of the "edit link" if a site is depending on anything other than core access permissions.

That's what Views uses to check access. $data is a faked up node that contains the nid, the uid and the type, which should be all of the data node_access actually needs. I'm not sure what else to tell you; feel free to investigate this further (views_node.inc, function views_handler_node_edit) to see if you can figure out what may be wrong on your system, but I don't see that there's anything wrong with this, and I don't have the time to spend hours trying to replicate your problem for you.

Thanks for the response! I understand your time constraints, as you maintain some pretty impressive modules for Drupal. I'll try to figure this out. Thanks again for the look at my problem.

Changing this to (needs more info) until you can find something that may be causing this. I suspect this isn't a Views issue but being node access, it's hard to tell where this issue exists.

I wish I was more PHP literate, as this would help me narrow down the issue in the code. Here's a little more information: the node permissions are working as expected. Users who have a role that allows them editing rights, get the rights-- the edit tab shows up when viewing the node itself. However, if the node is listed in a view with the "edit link" added, the edit links only show up for the original author of the node or the admin. The edit links do not show for a user who belongs to a role that has been given editing rights through an access module (like content access). I think it has to be a views issue, although I imagine third party access modules may make it difficult to address this. But the permissions are working properly for when the full node is viewed, just not in views.

I hope that helps. I wish I could do more to figure this out. I took a look at the code and determined that I was not prepared to discover a solution (I'm still a very new at doing anything with PHP-- though I have tried).

I ran into the same problem with views edit link and taxonomy_access. As a workaround I added "$data->status = 1" to the "faked up node" in views_node.inc. I'm not sure if this is some feature or bug and why node status should affect update permissions (in my case anyway). If you don't want to hack the views-module you can do your own edit link for example when overriding the views list theme function in template.php.

I had similar success. (patch removed from this comment)

Trying to mark this correctly. This patch is for 4.7.x.

...and for 5.x-dev.

I wonder, now that this issue is ironed out, if there would be a way to create a view filter of the content that a user can edit? I know this is more of a separate feature request, but I thought I would bring it up here, as is seems those of you patching this problem might realize how to do this filter. See http://drupal.org/node/220091

Thank you for the patches. This functionality will be greatly helpful in an environment where users may be given permission to edit content they did not create.

I just tested your patch with the 5x development version of views_node.inc file. It seems to work perfectly. A user who is given edit rights over a node through taxonomy access can now see the edit link, even when that user is not the author of the node. This is the behavior that is expected when using taxonomy access to grant edit rights within categories. Can this be committed (note, I wouldn't consider my testing extensive, but this patch seems simple enough)?

subscribing

Question about these patches: Is it not problematic to set $data->status = 1; whether or not the node is published? It seems that this could change the return value from node_access() in cases where a node is not actually published . Perhaps I've missed something here.

ezra-g: No, status = 1 because the node_access system absolutely and completely ignores unpublished nodes. I had totally not noticed this problem. Setting status = 1 should work just fine.

Committed.

Automatically closed -- issue fixed for two weeks with no activity.

ezra-g: No, status = 1 because the node_access system absolutely and completely ignores unpublished nodes. I had totally not noticed this problem. Setting status = 1 should work just fine.

Thats not so. The node access system has to get a valid value for status.. The patch that went in is incorrect. I posted a better one to #325357: Views handler for node 'edit' and 'delete' links' node access is faulty