Problem/Motivation
The latest revision tab shows, but when you click on its link you get a 403 page.
This scenario is created when you give anonymous users "View the latest version" permission, but not the "View any unpublished content" permission.
Here are steps to reproduce:
- Install Workbench Moderation and enable a content type to be moderated, with all moderation states enabled, and default state of draft
- Create a node for that content type and publish it
- Create a forward revision for that node by creating a new draft
- Set the "View the latest version" permission to "Anonymous User"
- Access the node as an anonymous user
- Notice you see the "Latest version" tab, click on it
- Notice you are taken to a 403 Access denied page
Proposed resolution
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | change-latest-version-permission-to-view-own-unpublished-content-2687789.patch | 1.12 KB | simfin |
| #12 | 2687789-latest-tab.patch | 5.93 KB | Crell |
Comments
Comment #2
Crell commentedDoes this happen without multiversion, or is it a multiversion-specific bug?
Comment #3
josephdpurcell commentedThis is a Workbench Moderation specific bug report. I've updated the description to clarify.
Comment #4
josephdpurcell commentedI have a clearer idea of what is happening. I've updated the description to reflect it.
I'm not sure this is actually a bug, but rather a need to understand that "View the latest version" permission doesn't make sense if the user cannot view the forward revision, e.g. the user doesn't have "View any unpublished content" permission.
I see two ways to improve this:
Comment #5
Crell commentedWhy decide? Let's do both. :-) That's probably best for UX.
Comment #6
josephdpurcell commentedI don't believe this patch works. It appears to me that
$this->moderationInfo->getLatestRevisionreturns the latest revision even if the user doesn't have access to it.Follow up would be to not just load the forward revision but verify the user has access, and secondly do item 2 in #4
Comment #7
Crell commentedCorrect. That method is explicitly not user-access-aware. That needs to get checked externally by this patch.
The account can be passed into the access() method, as one of the many magic values it can request. See how PermissionAccessCheck does it.
NULL is a bug. :-)
getLatestRevision() isn't user-aware either.
Comment #8
Crell commentedHere's a totally new take.
The test in this patch adds a test for the class, but turns out the fix itself doesn't even need to touch the class. However, writing a proper test for that requires BrowserTestBase, and placing blocks to get the tabs to show up, and after an hour-plus of trying to make that work I am giving up and just trusting that it works because I am sick to death of our testing framework at this point. :-(
If testbot likes the rest of this patch, I'll merge it shortly.
Comment #12
Crell commentedHm, need to tweak the permissions in the Simpletests. I keep forgetting those are even there.
Comment #14
Crell commentedMerged.
Comment #16
simfin commentedI have an issue with users who I want to view the Latest version tab, but I don't want them to have the 'View all unpublished content' permission, but only the 'View own unpublished content'. I have attached a patch for this particular situation.
Comment #17
mrdrewkeller commentedI've also run into the problem of not wanting to give users the "View any unpublished content" permission.
Is there a reason that was decided as a requirement rather than "View own unpublished content?"
So far in my testing the change in #16 works fine but would like to know why "View any unpublished content" is required.