I've run across something that looks like a bug in how Views handles the operations links field for users who have "edit own" permissions for the nodes displayed in the view. I don't see this reported in the issues queue yet.
A simplified description of the problem I've encountered:
- I added a new content type.
- Role X has "edit own" permissions for this content type, but no other node permissions except view published content.
- User A and User B both have Role X.
- Admin user creates two nodes of the new content type, and makes User A the author of one node, and User B the author of the other node.
- View is created to display all nodes of the new content type; the view includes the Operations Links field.
- When Admin is logged in, the operations links (Edit, Delete) are available in the view for both nodes (which is the expected behavior).
- User A logs in, and the Edit link is available in the view only for the node that has User A as author (which is the expected behavior).
Now, here's the problem:
User B logs in, and the Edit link is displayed in the view for User A's node, and not for the node that has User B as author. If User B clicks the view's Edit link for User A's node, User B gets the access denied message, because User B doesn't have edit access to User A's content.
If User B goes to the webpage for User B's own node, the Edit tab is available and functions properly, though.
This issue with the view happens regardless of whether Views cache is enabled or disabled, and regardless of whether "no cache" is set in the view's advanced settings. Clearing Views cache, clearing all caches through /admin/config/development/performance, and running cron do not resolve the problem.
This issue happens regardless of whether User A has logged off before User B logs on.
It happens regardless of the position of the operations links field in the view's arrangement of fields.
It happens with Bartik as the theme.
The only contrib module installed is Field Group 8.x-1.0-rc4 (the current version), but the problem persists when I uninstall Field Group and clear caches.
User A and User B are accessing the website on separate devices that are on different networks. The problem happens regardless of the web browser used (I've tried with IE11, Firefox, Chrome, Edge).
I've resorted to a workaround for my site, by removing the operations links field from that view and adding an additional Views block display that uses a content author relationship and contextual filter to provide "Edit" links only for nodes authored by the current user, and putting that block in a region on the page with the original view. The operations links field does work properly (i.e., User A and User B each get the Edit link for the correct node) in a view that uses the content author relationship and contextual filtering, but such a view displays only the current user's nodes.

| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2653690.png | 78.65 KB | felribeiro |
Comments
Comment #2
felribeiro commentedFor me it worked fine.
Comment #3
berdirRelated to or even a duplicate of #2473873: Entity operations lack cacheability support, resulting in incorrect dropbuttons I think.
Comment #4
acbramley commentedI've just encountered this same issue, I have a custom access handler through workbench_moderation (see #2708855: Provide edit permissions per state) to allow edit access to nodes per workbench state.
I have a role without edit access to "review" states, and the operations dropdown still shows the edit link (the delete link is correctly not displayed). Interestingly, the "Link to edit content" field which is a simple text edit link works correctly.
Comment #9
quietone commentedTested on 9.4.x,standard install. and was able to reproduce the problem using the steps in the IS. If I clear cache and reload the view for user 'b' then edit link is correctly placed for user b. If I then load the view as user 'a' then edit link is incorrectly shown for the user b content. If I clear cache and reload the view for user 'a' we are back to the situation described in the IS.
I then went looking for duplicates (there are a lot of views issues) and found #3012036: Views entity operations field does not contain required cache metadata and #2473873: Entity operations lack cacheability support, resulting in incorrect dropbuttons. There is a comment in the first one that says it is likely a duplicate of the second. The second one has a patch. I applied that, fortunately, it still applies, cleared cache and the views for user a and user b are now correct.
Therefore, closing as a duplicate of #2473873: Entity operations lack cacheability support, resulting in incorrect dropbuttons. If that is wrong, reopen the issue, by setting the status to 'Active', and add a comment.
Thanks!