Closed Bug 790361 Opened 13 years ago Closed 13 years ago

Implement view-only for contributors

Categories

(Developer Engagement :: Mozilla Hacks, task, P2)

x86
macOS

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: robert, Unassigned)

References

Details

(Whiteboard: [specification-like][type:feature])

Right now, most of the users of Mozilla Hacks have a role of contributos. That is because we don't want them to be able to post or change anyone else's post, or change settings for the blog. However, there are many times when we want people to be able to preview other people's post, without the right to edit it (and giving them Admin or Author roles is not an option). What we need is a way for anyone with a Mozilla Hacks account to be able to view a draft of any post, read-only. It doesn't have to be for the Admin interface, but at least for the preview URL.
Component: hacks.mozilla.org → Mozilla Hacks
Product: Websites → Mozilla Developer Network
Blocks: 854859
This turns out to be trickier than it seems... Drafts are only viewable by Admins, Editors, and the author of the post, all of whom also have the ability to edit. There's no way to make a Draft post viewable to a user without also allowing them to edit it, at least not with the built-in user capabilities WordPress offers (http://codex.wordpress.org/Roles_and_Capabilities). However, a post can be published privately. It's no longer treated as a Draft (post status is 'published'), but it's only viewable by Admins, Editors, and the post author by default. We can easily grant another role the ability to view private posts without granting them the ability to edit. You could publish a post privately to let people review it, edit as needed, then lift the privacy when you're ready to go live. The one snag with this workflow is that the publication date is set at the time the post is *first published*. If it's published privately and then made public later, the publication date stays the same and the newly-public post would not appear as "new", and any other posts published while it was private would be above it in the stream. You can change the publication date at the time you make it public so it's officially published "today", it just means you'll have to remember to do that. Not perfect, but it's probably the best workaround. So I've added the 'read_private_posts' capability for the Contributor and Author roles, and I've also added a new custom role called "Reviewer." A Reviewer can view private posts but do nothing else (they can't submit posts of their own like Contributors can).
Hmm, I see the issue. I think that would make the workflow harder than it is today, when you need to add authors instead to the post. Is it possible for people to preview and edit, but not publish?
(In reply to Robert Nyman from comment #2) > Hmm, I see the issue. > I think that would make the workflow harder than it is today, when you need > to add authors instead to the post. I thought changing the date would be much simpler and than granting Reviewers more privileges than they need. This would keep it truly read-only access for those users. Changing the date is easy, you'd just have to remember to do it. Also, if you schedule posts, setting the date is part of the process and thus impossible to forget. > Is it possible for people to preview and edit, but not publish? Yes, I believe we can let Reviewers edit other people's drafts but not publish them, if that's preferable to resetting dates. It does elevate their level of access so you'll just have to make sure they're not messing things up. WP keeps versions of posts automatically so you could always revert any unwanted changes. One other possibility is this Share a Draft plugin (http://wordpress.org/extend/plugins/shareadraft/). It creates a temporary URL to view a draft post, but the downside is that it's viewable by anyone who knows that URL (at least it's an obfuscated URL). There's no way to make a post private or password protected while also keeping it in Draft status.
> I thought changing the date would be much simpler and than granting > Reviewers more privileges than they need. This would keep it truly read-only > access for those users. True, but it's rather compared to adding those who need to review as authors to the post. Either way, it's a manual step before each publishing. > Also, if you schedule posts, setting the date is part of > the process and thus impossible to forget. Absolutely, but it's not very common. > Yes, I believe we can let Reviewers edit other people's drafts but not > publish them, if that's preferable to resetting dates. It does elevate their > level of access so you'll just have to make sure they're not messing things > up. WP keeps versions of posts automatically so you could always revert any > unwanted changes. Mmm, tricky. It's not optimal either. > One other possibility is this Share a Draft plugin > (http://wordpress.org/extend/plugins/shareadraft/). It creates a temporary > URL to view a draft post, but the downside is that it's viewable by anyone > who knows that URL (at least it's an obfuscated URL). There's no way to make > a post private or password protected while also keeping it in Draft status. Honestly, that seems like the best thing, though. Because it's not clear who will need to review, which, if any, account those users will have etc.
One more tiny wrinkle... We can allow a Reviewer to edit others' posts, but in doing so we must also allow them to submit new posts of their own (though not publish). Thus if you can edit, you can also submit. That's probably not a problem, I just wanted you to be aware of it. This now elevates a Reviewer to somewhere between a Contributor (who can submit but not publish, and can only edit her own posts) and an Editor (who can edit everyone's posts and also publish them). Neither a Contributor nor a Reviewer can edit posts once they're published, only while they're Draft or Pending. I initially wanted to make the Reviewer role very low access, strictly read-only with no ability to do anything else. This change makes a Reviewer a high-access Contributor/low-access Editor. They can make corrections to others' drafts, and can submit new posts of their own, but they still have no publishing power. Does that sound good?
> We can allow a Reviewer to edit others' posts, but in doing so we must also > allow them to submit new posts of their own (though not publish). Thus if > you can edit, you can also submit. That's probably not a problem, I just > wanted you to be aware of it. Not optimal, but worst case, we'll end up with a few unwanted drafts. > I initially wanted to make the Reviewer role very low access, strictly > read-only with no ability to do anything else. This change makes a Reviewer > a high-access Contributor/low-access Editor. They can make corrections to > others' drafts, and can submit new posts of their own, but they still have > no publishing power. Does that sound good? Again, not optimal, but it should be ok. I believe the risk of accidental editing should be low, and after all, reviewers are people we trust for input. An interesting relation to bear in mind here, though, is which roles will be able to add code to the posts (embed videos, code samples etc). Contributors will have to be able to do that, and then Reviewers will get that by default as well, correct?
(In reply to Robert Nyman from comment #6) > An interesting relation to bear in mind here, though, is which roles will be > able to add code to the posts (embed videos, code samples etc). Contributors > will have to be able to do that, and then Reviewers will get that by default > as well, correct? You'll have to allow Reviewers to post unfiltered HTML or else that code would be stripped when they save their edits.
> You'll have to allow Reviewers to post unfiltered HTML or else that code > would be stripped when they save their edits. Yeah, kinda what I figured.
Priority: -- → P2
Whiteboard: [specification-like][type:feature]
Blocks: 859921
See bug 851269 for more details about roles and capabilities. It'll go to production with bug 861445. The Reviewer role can edit unpublished drafts but cannot publish them.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: Mozilla Developer Network → Developer Engagement
You need to log in before you can comment on or make changes to this bug.