Status

Mozilla Developer Network
Wiki pages
--
enhancement
RESOLVED WONTFIX
6 years ago
9 months ago

People

(Reporter: openjck, Unassigned)

Tracking

Details

(Whiteboard: [user-interview][triaged][type:feature])

(Reporter)

Description

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

Comment 1

6 years ago
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.
(Reporter)

Updated

6 years ago
Whiteboard: u=visitor c=users p= → [user-interview] u=visitor c=users p=

Updated

6 years ago
Blocks: 757245
Priority: -- → P2

Comment 2

6 years ago
This is the default for Kuma
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

5 years ago
Version: Kuma → unspecified
(Assignee)

Updated

5 years ago
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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)
Depends on: 677814
(Reporter)

Updated

5 years ago
Whiteboard: [user-interview] u=visitor c=users p= → [user-interview]

Comment 5

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

Updated

4 years ago
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago4 years ago
Resolution: --- → DUPLICATE
Duplicate of 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Updated

4 years ago
Whiteboard: [user-interview] → [user-interview][triaged]
(Reporter)

Updated

4 years ago
Whiteboard: [user-interview][triaged] → [user-interview][triaged][type:feature]

Updated

4 years ago
Severity: normal → enhancement
Priority: P2 → --
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.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.