It looks like there is trouble with the edit links (provided by a view) respecting node editing rights. I have taxonomy access handling the bulk of my permissions for my site, but I need a node access module to allow edits of content not authored by the user. I have tried Simple Access, Node Access, and Content Access with the same results: the edit links don't show up in views for nodes not authored by the user, no matter what the node access module says. I've tried clearing the views cache and site cache, plus rebuilt my permissions table with each attempted module. When viewing the full node, the edit link appears in the expected manner, so I do suspect this is an issue with the way the views "edit" links respect the various permissions. I'm using Drupal 5.2, Taxonomy Access Control 5.x-1.1, Content Access 5.x-1.x-dev, and ACL 5.x-1.4 (Access control list API). Can someone else verify this problem and find a fix? Thank you!

CommentFileSizeAuthor
#9 views-diff-2008-02-13-14-35-52.patch1.66 KBdeekayen
#8 views-diff-2008-02-13-14-35-21.patch1.82 KBdeekayen
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bomarmonk’s picture

bomarmonk CreditAttribution: bomarmonk commented
Priority: Normal » Critical

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.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Priority: Critical » Normal 
  if (node_access('update', $data)) {

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.

bomarmonk’s picture

bomarmonk CreditAttribution: bomarmonk commented

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.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Status: Active » Postponed (maintainer needs more info)

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.

bomarmonk’s picture

bomarmonk CreditAttribution: bomarmonk commented

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).

anttih’s picture

anttih CreditAttribution: anttih commented

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.

deekayen’s picture

deekayen CreditAttribution: deekayen commented
Version: 5.x-1.6 » 5.x-1.x-dev
Status: Postponed (maintainer needs more info) » Needs review

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

deekayen’s picture

deekayen CreditAttribution: deekayen commented
Version: 5.x-1.x-dev » 4.7.x-1.x-dev
FileSize
views-diff-2008-02-13-14-35-21.patch1.82 KB

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

deekayen’s picture

deekayen CreditAttribution: deekayen commented
Version: 4.7.x-1.x-dev » 5.x-1.x-dev
FileSize
views-diff-2008-02-13-14-35-52.patch1.66 KB

...and for 5.x-dev.

bomarmonk’s picture

bomarmonk CreditAttribution: bomarmonk commented

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.

bomarmonk’s picture

bomarmonk CreditAttribution: bomarmonk commented
Status: Needs review » Reviewed & tested by the community

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)?

geek-merlin’s picture

geek-merlin
they/omg
Primary language German
Location Freiburg, Germany
CreditAttribution: geek-merlin commented

subscribing

ezra-g’s picture

ezra-g CreditAttribution: ezra-g commented

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.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented

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.

merlinofchaos’s picture

merlinofchaos CreditAttribution: merlinofchaos commented
Status: Reviewed & tested by the community » Fixed

Committed.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Closed (fixed)

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

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

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