768498 - Access control for editing

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Editing, defect)

Description

[Les Orchard [:lorchard]]

There's currently no way to lock an individual page down for editing by admins only. This could be handy for something like bug 768492, or for protecting heavily-trafficked top-level topic landing pages.

We could look into more granular permissions or editing groups later, but for now this bug just asks for a simple on/off checkbox to restrict editing just to addons. Don't expose the checkbox in normal wiki editing, require access to Django admin to modify.

For bonus points, expose the checkbox in the changelist view, so multiple pages can be modified at once.

Comment 1

[John Karahalis [:openjck]]

Sheppy: How important would you say this is?

Comment 2

[Eric Shepherd [:sheppy]]

This can wait, although it's possible a "crisis" might arise where we suddenly need it very badly.

Comment 3

[Les Orchard [:lorchard]]

Note that this is also a blocker to a general solution for a wiki-editable CSS stylesheet in bug 768492.

Without the ability to lock pages, the next best hack we have is to create the CSS resource as a template. Then, we can at least lean on the template-editing permission, as long as we're okay with all template editors having access to also edit the CSS

Comment 4

[Les Orchard [:lorchard]]

I came up with a hack for CSS editing, and I think the vibe otherwise is that this is a non-essential feature for launch

Comment 5

[Fred Wenzel [:wenzel]]

This would be one viable solution for automating yet protecting the content transfer from MDN to DevHub. Is there a chance to get this onto the roadmap for September?

Comment 6

[Eric Shepherd [:sheppy]]

I don't know if this is going to make it to MDN that soon. John, where did it wind up on our priority list?

I don't even recall if per-page access controls made it onto our six-month plan.

Comment 7

[Jean-Yves Perrier [:teoli]]

It didn't. I think John put some priority on it in July. Mainly in case of an editing war, but we ditched this to P3.

Comment 8

[Luke Crouch [:groovecoder]]

First document on the list:

docs/Promote-MDN 

should power the Promote MDN WordPress plugin and only be editable by The SEO Task Force™

Comment 9

[John Karahalis [:openjck]]

(In reply to Eric Shepherd [:sheppy] from comment #6)
> I don't know if this is going to make it to MDN that soon. John, where did
> it wind up on our priority list?
> 
> I don't even recall if per-page access controls made it onto our six-month
> plan.

I don't think we talked about this in Toronto. At least I don't see it in the notes.

https://etherpad.mozilla.org/MDN-Toronto-2012

We will further sort through what we talked about after we finish a couple of sprints worth of important post-launch work.

Comment 10

[Les Orchard [:lorchard]]

FWIW, this is the bug we need to fix so we can stop naming pages Template:something that aren't actually kumascript templates.

Comment 11

[Les Orchard [:lorchard]]

Simplified the title, because I can never find this bug

Comment 12

[Les Orchard [:lorchard]]

Mostly as a note to myself, but feel free to discuss - I've had a notion to build a django app to support creation and management of "teams":

http://blog.lmorchard.com/2013/02/23/looking-for-a-django-app-to-manage-roles-within-groups

Initially, I'd thought this would be mainly useful for badges.mozilla.org. But, it could also be handy as a self-service tool we use to offer for users to form groups & manage roles and permissions with respect to documents created and managed by group members.

That is, someone could start the "/docs/*/SomeNewProject" subtree of wiki pages and form a "SomeNewProject" team to support it. Only members of that team with the appropriate role-based permissions would be able to edit pages beneath "/docs/*/SomeNewProject". Certain members of the team (ie. starting with the founding member) would have permissions to manage team membership & roles & permissions, etc.

Of course, site-wide admins would still have permission to do anything anywhere, but this could help subdivide responsibilities in an organic way.

Comment 13

[Eric Shepherd [:sheppy]]

This is highly relevant to the new zone and devhub work we're doing; we'll need to be able to create landing pages and other semi-static content for zones and have them be locked to only be editable by particular teams.

So we'll need "group" support as well, for these access permissions.

Odds are we will also need to be able to have pages only visible to these groups, so they can pre-stage content before deployment, in some cases.

Comment 14

[Les Orchard [:lorchard]]

Going to take a swing at this bug, probably as I mentioned in comment 12

Comment 15

[Eric Shepherd [:sheppy]]

We'll almost certainly want to be able to do both "Set this page's permissions" and "Set this page and all its subpages' permissions", fwiw, if that's not mentioned above.

Comment 16

[Eric Shepherd [:sheppy]]

To sum up the specific kinds of permissions we'll need:

- Page/tree is only editable by specific people
- Page/tree is only VISIBLE to specific people (to be used while constructing content prior to a launch or announcement)
- Subpages can only be created by specific people

Keep in mind that pages that are only visible to specific people shouldn't show up in search results for anyone else.

Comment 17

[Les Orchard [:lorchard]]

Finally getting a change to dig in, and realizing that scope is really creeping on this bug with requirements in comments.

We have bug 757245 for overall permissions in kuma, and this bug is *only* meant to be about per-page access control for editing. Going to do a little bit of bug gardening to try to rebalance these bugs into more bite-sized-scope tasks.

Comment 18

[Les Orchard [:lorchard]]

Tweaking the title. Also, per comment 16, it's worth noting we have bug 677806 for access control on reading pages.

Comment 20

[Les Orchard [:lorchard]]

Popping up a level on the dependency stack - bug 677814 will cover the permissions and group management infra and UI that this bug needs first.

Comment 21

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/52806890615ff8be7e1d9c494ebcebb9d956f3b4
bug 768498: Initial steps toward access control for wiki with teams & policies

https://github.com/mozilla/kuma/commit/a5b36ab82c1eab40904a856ee9fc4df26b821287
Merge pull request #1197 from lmorchard/768498-access-control

bug 768498: Initial steps toward access control for wiki with teams & policies

Comment 23

[Les Orchard [:lorchard]]

Simplifying bug title

Comment 24

[Shafiul Azam]

Hi,

May I please add that instead of completely revoking access to edit certain pages, may we allow edit and will require moderator/admin's/regular contributors' approval to go live? We face this problem many time when new contributors try to localize articles and do mistakes. Moreover, these localized articles don't have "Review Needed" checkbox with them. In those cases, needing admin approval before an article goes live will help greatly.

Or maybe, the very first article edited/created by new contributors could require review by regular contributors.

Comment 25

[Eric Shepherd [:sheppy]]

(In reply to Shafiul Azam from comment #24)
> Hi,
> 
> May I please add that instead of completely revoking access to edit certain
> pages, may we allow edit and will require moderator/admin's/regular
> contributors' approval to go live? We face this problem many time when new
> contributors try to localize articles and do mistakes. Moreover, these
> localized articles don't have "Review Needed" checkbox with them. In those
> cases, needing admin approval before an article goes live will help greatly.

I like the idea of one of the possible permission settings for a page be "Moderation required". So pages would have the following possible permissions:

* Anyone can edit
* Editable only by group X
* Editable only by admins
* Anyone can edit but edits must be moderated by group X (or admin)

> Or maybe, the very first article edited/created by new contributors could
> require review by regular contributors.

This is also a great idea; I think we have a bug somewhere for this, but am not certain.

Comment 26

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.