Closed Bug 431348 Opened 12 years ago Closed 11 years ago

Hide "Sandbox/Internal Testing Area" category from editor for non-administrators

Categories

(support.mozilla.org :: Knowledge Base Software, task)

task
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: djst, Assigned: ecooper)

Details

(Whiteboard: sumo_only)

We're not using it anymore and it's confusing for approvers/localizers.
I use it...
For what?

But I guess the issue here is that approvers/locale leaders shouldn't see it. If there is a real need for it, we can morph this bug to be about the visibility of it.
I use it as a sandbox/internal testing area :)

I use it when I want to try out fool around with syntax/formatting to reproduce a bug or to work out how certain things work. I imagine others use it in the same way.

What's so confusing about it?
Looking at the action log for the past month:
<http://support.mozilla.com/tiki-admin_actionlog.php?startDate_Month=03&startDate_Day=29&startDate_Year=2008&endDate_Month=04&endDate_Day=29&endDate_Year=2008&categId=7&unit=bytes&contribTime=w&list=Report#Report>

(I tried using support-stage.mozilla.org, but the action log page kept timing out)

There are a few people that use it for varying reasons:
- villep just used it by mistake.
- I use it to test tikiwiki markup, showfor, code for dynamic content, and creating diffs for cases when some edits an article that does not yet have a staging copy.
- Cww used it to redo the Best Practices doc, which is in the Admin category, as well as test syntax for centering items in tables.
- Lucy and David used it to work on the sumodayevents article.

I assume this bug was reported because of villep mistakingly putting his (her?) articles in that category. Is that correct?

If we were to remove it, I suppose we could use the staging area.
I think it's confusing because it makes redundancy with Staging Area. I'm an approver and see no differences between Sandbox and Staging Area, as some others localizers. :)
More than one localizer has asked what it's for and which category to choose. I'm fine with keeping the category if it's indeed useful, but I strongly think it should not be visible to regular contributors, approvers, and localizers; it should only be visible to admins (and potentially a "Hacker" user category if it turns out that there are other hard-core community members who use this regularly too).
Summary: Remove "Sandbox/Internal Testing Area" category → Hide "Sandbox/Internal Testing Area" category for non-administrators
(In reply to comment #4) 
> I assume this bug was reported because of villep mistakingly putting his (her?)
> articles in that category. Is that correct?

Almost correct, see comment 5 for another localizer. I don't think there's been any localizer _not_ asking about it among the people I've talked to, and I doubt localizers find it useful. The only non-admin contributor who deliberately used the category is Cww, and I'd say he qualifies for the suggested "Power Contributor" user who should be able to see it.

The bottom line is that I want to make SUMO as easy to use for new contributors as possible, and this just happens to be one of those confusing things that people ask about. It's only useful to a limited group of people, so it should not be visible for others.
I would rather move the testing articles to the staging area, and put a note at the top saying that the article is for testing purpose (not intended to be moved to public visibility), than hide the sandbox category.

Hiding the category just prevents people from using it, who may want to use it.
(In reply to comment #8)
> I would rather move the testing articles to the staging area, and put a note at
> the top saying that the article is for testing purpose (not intended to be
> moved to public visibility), than hide the sandbox category.

I thought the two were the same... What's the difference?
David Tenser already told me that this category hides the article from outside access. So does the sandbox category. It's redundant, no?
Staging Area is for staging copies of KB articles (in our staging and approval system), and drafts of new KB articles not yet approved for the KB.

Sandbox is for testing.
We should open the Article Sandbox "article".
Note: Using the staging area for sandbox articles/edits affects weekly metrics.
Assignee: nobody → smirkingsisyphus
Whiteboard: see comment 6
Target Milestone: --- → 0.9
I'm not sure what the status of this is, but this can be done via category permissions in tiki-admin_categories.php.

In any case, I'm not sure if my assistance is needed.This is just permissions change on prod.
Target Milestone: 0.9 → 1.1
Ok, I changed the permissions...
I didn't check what it looked like before but it doesn't show up now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Removing the ability to view articles in the sandbox seems like overkill, because we sometimes refer to sandbox articles in bugs. It should just be removed from the editor.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Hide "Sandbox/Internal Testing Area" category for non-administrators → Hide "Sandbox/Internal Testing Area" category from editor for non-administrators
I didn't remove the ability to view articles.  I just removed the ability to set that category.
Logged in as "Chris_Ilias_user" which is currently an approver (not locale leader or admin), if I go to <http://support.mozilla.com/en-US/kb/Article+Sandbox>, I get a "Permission denied you cannot view this page" error.
Hmmm... I may have messed up, let me try again.
Oooops, I must have taken out view_category as well.  It's back.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Cheng, can you apply this to staging?
Done.
Verified FIXED on https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Cannot+connect+after+upgrading+Firefox with "hammeriusb", which is my Contributor (but not Admin) account.
Status: RESOLVED → VERIFIED
Target Milestone: 1.1 → 1.0
Whiteboard: see comment 6 → sumo_only
You need to log in before you can comment on or make changes to this bug.