In his user interview, Sheppy noted that MindTouch provides a user permission for reading content. Let's make sure Kuma has the same.

From what I understand, the thinking is that this permission should be granted to users by default. As such, this depends on neither bug 677814 nor bug 677816.

This is the default for Kuma

Reviving this bug, vs filing a new one. Looks like there is a call for restricting readability of pages to certain groups: https://bugzilla.mozilla.org/show_bug.cgi?id=768498#c16

Copying over the concern from bug 768498: - Page/tree is only VISIBLE to specific people (to be used while constructing content prior to a launch or announcement)

Is this bug a duplicate of the "hide in process content" permissions bug: 862010

This is not a duplicate of bug 862010. That bug is about a review process of changes that may actually be visible before being accepted as official. This bug is about whether or not a page may be visible at all to various users.

Kuma hasn't had this feature for 6 years, and I can't see a reason to prioritize adding it in the next six. Kuma supports hiding content from internal site search by adding a user: prefix. A similar strategy could be used to restrict some content from external search crawlers with a <meta> tag. But that would be better handled by a more focused bug. Review tags are used to ask for editorial or technical review, and tell visitors that a document may not be up to quality standards. There are additional tags for "in translation", and KumaScript macros to add content warnings. The last time I can recall needing a feature like this was during the "MDN at 10" effort in 2015. The page was constructed on the staging server, and then copied to the production server to make it live. There was an issue with links to images attached to the staging server, but these were discovered a month or more after launch. The staging server or a local development server could be used to author content before making it live on production.