Closed
Bug 768498
Opened 12 years ago
Closed 4 years ago
Access control for editing
Categories
(developer.mozilla.org Graveyard :: Editing, defect)
developer.mozilla.org Graveyard
Editing
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: lorchard, Unassigned)
References
Details
(Whiteboard: [type:feature][dev-ecosystem])
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•12 years ago
|
||
Sheppy: How important would you say this is?
Comment 2•12 years ago
|
||
This can wait, although it's possible a "crisis" might arise where we suddenly need it very badly.
Reporter | ||
Comment 3•12 years ago
|
||
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
Blocks: 768492
Reporter | ||
Comment 4•12 years ago
|
||
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
Updated•12 years ago
|
Whiteboard: u=user c=wiki s=2012-07-18 p=
Updated•12 years ago
|
Whiteboard: u=user c=wiki s=2012-07-18 p= → u=user c=wiki p=
Reporter | ||
Updated•12 years ago
|
Blocks: 757245
Summary: kuma: Flag to lock editing per-document for admins only → kuma: Flag to lock editing per-document for admins or specific groups
Comment 5•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
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•11 years ago
|
||
(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.
Assignee | ||
Updated•11 years ago
|
Version: Kuma → unspecified
Assignee | ||
Updated•11 years ago
|
Component: Docs Platform → Editing
Reporter | ||
Comment 10•11 years ago
|
||
FWIW, this is the bug we need to fix so we can stop naming pages Template:something that aren't actually kumascript templates.
Reporter | ||
Comment 11•11 years ago
|
||
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
Updated•11 years ago
|
Summary: kuma: Per-page access control for editing → Per-page access control for editing
Whiteboard: u=user c=wiki p= → p=
Updated•11 years ago
|
Priority: -- → P2
Whiteboard: p= → [dev-ecosystem]
Reporter | ||
Comment 12•11 years ago
|
||
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.
Updated•11 years ago
|
Whiteboard: [dev-ecosystem] → [type:feature][dev-ecosystem]
Updated•11 years ago
|
Priority: P2 → P1
Comment 13•11 years ago
|
||
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.
Reporter | ||
Comment 14•11 years ago
|
||
Going to take a swing at this bug, probably as I mentioned in comment 12
Assignee: nobody → lorchard
Comment 15•11 years ago
|
||
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•11 years ago
|
||
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.
Reporter | ||
Comment 17•11 years ago
|
||
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.
Reporter | ||
Comment 18•11 years ago
|
||
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
Reporter | ||
Comment 20•11 years ago
|
||
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•11 years ago
|
||
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
Updated•10 years ago
|
Priority: P1 → --
Reporter | ||
Comment 23•10 years ago
|
||
Simplifying bug title
Summary: Per-page and section-recursive access control for editing → Access control for editing
Comment 24•10 years ago
|
||
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•10 years ago
|
||
(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.
Reporter | ||
Updated•8 years ago
|
Assignee: lorchard → nobody
Comment 26•4 years ago
|
||
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
Updated•4 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•