Closed Bug 768498 Opened 12 years ago Closed 4 years ago
Access control for editing
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.
Sheppy: How important would you say this is?
This can wait, although it's possible a "crisis" might arise where we suddenly need it very badly.
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
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
Whiteboard: u=user c=wiki s=2012-07-18 p= → u=user c=wiki p=
Summary: kuma: Flag to lock editing per-document for admins only → kuma: Flag to lock editing per-document for admins or specific groups
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?
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.
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.
First document on the list: docs/Promote-MDN should power the Promote MDN WordPress plugin and only be editable by The SEO Task Force™
(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.
Component: Docs Platform → Editing
FWIW, this is the bug we need to fix so we can stop naming pages Template:something that aren't actually kumascript templates.
Simplified the title, because I can never find this bug
Summary: kuma: Flag to lock editing per-document for admins or specific groups → kuma: Per-page access control for editing
Summary: kuma: Per-page access control for editing → Per-page access control for editing
Whiteboard: u=user c=wiki p= → p=
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.
Whiteboard: [dev-ecosystem] → [type:feature][dev-ecosystem]
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.
Going to take a swing at this bug, probably as I mentioned in comment 12
Assignee: nobody → lorchard
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.
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.
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.
Tweaking the title. Also, per comment 16, it's worth noting we have bug 677806 for access control on reading pages.
Summary: Per-page access control for editing → Per-page and section-recursive access control for editing
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.
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
Simplifying bug title
Summary: Per-page and section-recursive access control for editing → Access control for editing
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.
(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.
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/.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.