Grant editcontentmodel right to all logged in users
Open, NormalPublic

Description

Users with the editcontentmodel right can create a revision with a different contenttype and contentmodel. Before we grant anyone the right on a wiki we need to address technical issues with this capability.

One possible use case for this right is the group of users to whom we grant permission to run T72073 (Special page to enable Flow on pages).

2016-03-08: status from T85847#2101567
editcontentmodel is only granted to the sysop group by default.

Remaining steps:

  • Address blocker: T128556: Document editcontentmodel
  • send out announcements/write release notes
  • make sure nothing blows up (a week or two after announcing)
  • grant it to the 'user' group.

@Legoktm suggests that editcontentmodel should be on the same level as page moves

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

All blockers are currently resolved, so I've uploaded a patch to grant this right to the sysop group for now, with the expectation that if no bugs are found, we can expand it to the 'user' group (probably not '*' due to logging stuffs?)

All blockers are currently resolved, so I've uploaded a patch to grant this right to the sysop group for now, with the expectation that if no bugs are found, we can expand it to the 'user' group (probably not '*' due to logging stuffs?)

I'm not sure what your parenthetical means. We have logging.log_user_text now.

I think we should treat 'editcontentmodel' the same way we treat 'move' in MediaWiki core.

Hi @Legoktm - Is this right stable/usable now? I was wondering if we could have it enabled for sysops and massmessage senders on Meta since there are special pages that allows you to build massmessage lists, but ain't usable now due to users not having this permission. Best regards.

Change 196981 merged by jenkins-bot:
Grant 'editcontentmodel' to all sysops by default

https://gerrit.wikimedia.org/r/196981

Harej added a comment.Mar 8 2016, 5:55 PM

As I understand, editcontentmodel is currently being rolled out to WMF wikis. Does this mean this problem is resolved?

RobLa-WMF closed this task as Resolved.Mar 8 2016, 6:46 PM

This appears to have been a tracking bug, and 4/5 of the blocked issues (T72592, T72901, T73163, T75490) are marked resolved. @daniel's T78634 is "declined", but it's probably long past time for him to raise a stink about it.

I think this one can be safely resolved. Please reopen if you disagree.

Legoktm reopened this task as Open.Mar 9 2016, 12:11 AM

Sorry, not fixed yet :(

Currently it's only granted to the sysop group by default. I think the last remaining blocker is T128556: Document editcontentmodel, send out announcements/write release notes, make sure nothing blows up (a week or two after announcing), and then grant it to the 'user' group.

We should be aiming to get editcontentmodel on the same level as page moves basically.

RobLa-WMF updated the task description. (Show Details)Mar 9 2016, 1:22 AM
RobLa-WMF set Security to None.
Harej renamed this task from issues with granting the editcontentmodel right to Grant editcontentmodel right to all logged in users.May 30 2016, 12:18 PM

I'm thinking there are some security related concerns with this proposal depending on where checks take place. For example, would "user" be able to changecontentmodel on another user's subpage - to bypass the protection on js/css controls, then change it back and make them go live?

We could, perhaps, make it so that some pages cannot have their content model changed.

I'm thinking there are some security related concerns with this proposal depending on where checks take place. For example, would "user" be able to changecontentmodel on another user's subpage - to bypass the protection on js/css controls, then change it back and make them go live?

This should not be possible. As far as I know, this is not possible.

Harej added a comment.Sep 3 2016, 2:01 AM

I did some experiments on my test wiki and found that with editcontentmodel enabled for all users, I still was not able to make changes to another user's vector.js. In this screenshot I, as generic user Gimp2, tried to change the content model of Gimp's vector.js page. MediaWiki rightfully did not allow it.

Okay, all blockers resolved! I'm going to submit a patch to core to grant editcontentmodel to 'user' (equivalent to 'move'). And then a patch to wmf-config which grants 'editcontentmodel' to wikis at the same level they've granted move, to keep the permissions on basically equal settings. Individual wikis would be able to further request configuration changes to adjust if necessary. Once the core patch is merged and we have a date for deployment, I'll send out an announcement to wikitech-ambassadors.

Change 309061 had a related patch set uploaded (by Legoktm):
Grant 'editcontentmodel' permission to 'user' group

https://gerrit.wikimedia.org/r/309061

Change 309061 merged by jenkins-bot:
Grant 'editcontentmodel' permission to 'user' group

https://gerrit.wikimedia.org/r/309061

Change 309066 had a related patch set uploaded (by Legoktm):
Match 'editcontentmodel' permission with 'move'

https://gerrit.wikimedia.org/r/309066

JJMC89 added a subscriber: JJMC89.Sep 7 2016, 8:31 PM
Xaosflux added a comment.EditedSep 8 2016, 12:49 AM

I'm a bit concerned about this access for projects that don't have some special Flow related requirement (actually most projects - special flow things should have their own utility). editcontentmodel users are able to "break" pages such as encyclopedia articles from being accessed by readers. Such a break can not be reverted by logged out users, and would require another user to have knowledge of the contentmodel change utility to restore such an article.

I understand the utility for letting (massmessage) holders use this - and suggest that it is deployed to (massmessage) holding groups instead of (move) holding groups by default. (Any of course any project could request it be included in any group as per most permissions).

Thoughts?

@Legoktm ping to you regarding my above comment - please let me know if I'm missing some part of the "big picture". Us enwiki people can discuss and request a project specific update if there is a consensus against this there.

I'm a bit concerned about this access for projects that don't have some special Flow related requirement (actually most projects - special flow things should have their own utility). editcontentmodel users are able to "break" pages such as encyclopedia articles from being accessed by readers. Such a break can not be reverted by logged out users, and would require another user to have knowledge of the contentmodel change utility to restore such an article.

I understand the utility for letting (massmessage) holders use this - and suggest that it is deployed to (massmessage) holding groups instead of (move) holding groups by default. (Any of course any project could request it be included in any group as per most permissions).

Thoughts?

The reason Flow has a separate system is because of this bug actually - editcontentmodel wasn't granted to enough people to make it obey the permission system. MassMessage didn't have enough development resources to implement a totally separate system, so it is kind of crippled until this bug is finally fixed. And in the future I know at least CollaborationKit (for WikiProjects) plans to take advantage of this functionality by providing structured content models on normally namespaced pages.

Like any new feature, there's always room for people to abuse it. We are widening the amount of users who can convert pages (to autoconfirmed on enwp), but it's also increasing the number of people who can revert malicious changes. I've long stated that conceptually this is equal to the 'move' permission, and I think

sorry, hit submit too early.

...I've long stated that conceptually this is equal to the 'move' permission, and I think, we've done a good job in keeping it mostly the same. Similar permission level granting, special page to make and undo changes, convenient revert link in summaries, API ability, etc. The only thing not there is a link in the UI to make the change (move has a tab, this has nothing). But not exposing it in the UI is a conscious choice because most users should really never have to use it. But we don't want to enforce that technically with permissions.

And I just realized we didn't have rate limits for this, so submitted a patch for that: https://gerrit.wikimedia.org/r/309224

So making "undo" work for these will not be enabled until the permission is changed?

Here are examples:

https://test2.wikipedia.org/w/index.php?title=Law2&action=history
https://en.wikipedia.org/w/index.php?title=User:Xaosflux/Test1&action=history

Click undo - does not work, instead errors out.

[V9DF6QpAEK0AAC8UbGwAAABI] /w/index.php?title=Law2&action=edit&undoafter=296827&undo=296828 MWException from line 570 of /srv/mediawiki/php-1.28.0-wmf.18/includes/content/ContentHandler.php: Bad content model: expected json but got wikitext.

Backtrace:

#0 /srv/mediawiki/php-1.28.0-wmf.18/includes/content/ContentHandler.php(1023): ContentHandler->checkModelID(string)
#1 /srv/mediawiki/php-1.28.0-wmf.18/includes/page/WikiPage.php(1352): ContentHandler->getUndoContent(Revision, Revision, Revision)
#2 /srv/mediawiki/php-1.28.0-wmf.18/includes/EditPage.php(1128): WikiPage->getUndoContent(Revision, Revision)
#3 /srv/mediawiki/php-1.28.0-wmf.18/includes/EditPage.php(1046): EditPage->getContentObject(boolean)
#4 /srv/mediawiki/php-1.28.0-wmf.18/includes/EditPage.php(606): EditPage->initialiseForm()
#5 /srv/mediawiki/php-1.28.0-wmf.18/includes/actions/EditAction.php(59): EditPage->edit()
#6 /srv/mediawiki/php-1.28.0-wmf.18/includes/MediaWiki.php(505): EditAction->show()
#7 /srv/mediawiki/php-1.28.0-wmf.18/includes/MediaWiki.php(289): MediaWiki->performAction(Article, Title)
#8 /srv/mediawiki/php-1.28.0-wmf.18/includes/MediaWiki.php(750): MediaWiki->performRequest()
#9 /srv/mediawiki/php-1.28.0-wmf.18/includes/MediaWiki.php(521): MediaWiki->main()
#10 /srv/mediawiki/php-1.28.0-wmf.18/index.php(43): MediaWiki->run()
#11 /srv/mediawiki/w/index.php(3): include(string)
#12 {main}

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#restrict_changecontentmodel_permission
has been created to discuss if this is something that the English Wikipedia will want to restrict to less users

+Consensus needed tag; this is under discussion on enwiki - and we should not assume that all other projects need to have most users altering content models for pages.

I'm not convinced, per above, that rolling this right on WMF wikis to all
users or even autoconfirmed users is a good idea. This right is for a very
specific work.

Alsee added a subscriber: Alsee.Sep 9 2016, 9:45 AM

This task should be declined. It is just pointless disruption to let zero-rights-users screw with the content model of random pages. Utilizing massmessage requires advanced permissions to send out the messages anyway. Obviously someone with advanced permissions can handle the rare and trivial creation of the page in the first place.

This task should be declined. It is just pointless disruption to let zero-rights-users screw with the content model of random pages. Utilizing massmessage requires advanced permissions to send out the messages anyway. Obviously someone with advanced permissions can handle the rare and trivial creation of the page in the first place.

I'm more than happy to engage with people over this issue, but I ask that you actually read what's been said here (and other places, sorry the discussion is so fragmented) - because your statements make it clear that you haven't. If you're going to make statements like "pointless disruption" or "rare and trivial creation", you need to back them up with facts. Because as I've stated here and elsewhere, it's not pointless, nor is rare.

This right is for a very specific work.

I don't follow how that is an argument to not grant this right to a wider set of users. For example, the "transcode-reset" right is granted to autoconfirmed users - wouldn't you say that is needed only for very specific set of work?

With the difference that transcode-reset does not disrupt pages. This does, and it's not okay. This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

Harej added a comment.Sep 10 2016, 1:32 PM

This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

It is currently true that it is really only useful for mass message senders, but this will not be true in the long term as new features come out that involve custom content models. (An extension I am working on, CollaborationKit, is one such example of that.)

That considered I personally am open to the idea of restricting arbitrary content changes while allowing people to create non-default content model pages through pre-specified workflows.

With the difference that transcode-reset does not disrupt pages. This does, and it's not okay. This is for a very specific work that massmessage-senders and sysops can perform. Others do not need this, so there's no point on adding a right that will have no use for them and that has room for abuse.

We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page.

We should empower users to be bold. :-) I favor as liberal permissions as possible in nearly all cases as I think that's the wiki way. In the case of editing a content model, it should not be any more disruptive than moving/renaming a page.

Yup, the wiki way is wonderful. Classically speaking:

  1. User A makes change X
  2. User B sees change X, quickly evaluates its merit, and can enhance it (or undo it)

There's a symmetry of power in the wiki way. Both "A" and "B" are equally powerful to make the change, so "A" can be bold.

The wiki way ends up breaking when it's possible for user "A" to make changes that user "B" doesn't notice, doesn't understand, or has to work harder than user "A" to undo.

@Legoktm and @andymw, thanks for making sure that we note the blockers for opening up wider access (T145316, T145344, T145489). The discussion on those subtasks (mainly T145344 as of this writing) is educational.

Putting a note here that at least on enwiki, changing the content model of a userjs page away from js can open it up for public editing. See last discussion on https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=757400754

Judging by this task still being open, I take it this hasn't happened yet?

Seems like. Also, the concern I noted before about this privilege allowing one to potentially sidestep editing restrictions on user CSS/JS pages needs to be resolved.

stjn added a subscriber: stjn.EditedApr 20 2018, 10:23 PM

It seems like there are some legitimate cases for this (such as Flow talk pages, although Flow is not used quite enough to have WMF-wide decision made based specifically on it) and there are some possibilities that this can prove pretty pointless and maybe even harmful. For example, what is the case for having content model changes available in the main space? That just seems like a possible abuse tool for making pages render badly for some time.

If such a possibility is really needed, then it should be split off into additional settings on different types of content models. The permanent ability to turn an article into a JavaScript page is not a needed one.

Dcljr added a subscriber: Dcljr.Aug 23 2018, 8:48 AM

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#restrict_changecontentmodel_permission
has been created to discuss if this is something that the English Wikipedia will want to restrict to less users

FYI, the discussion Xaosflux was pointing to is now found at:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_134#restrict_editcontentmodel_permission

(This is probably not needed anymore, but it took me so long to find where this VP discussion was archived [a search of "all village pumps & archives" didn't find it, for some reason], I figured I'd post it here.)

MarcoAurelio added a comment.EditedAug 23 2018, 10:15 AM

But is that still happening? If so it's a real blocker IMHO.

Edit: I'm refering to T85847#2959070.

Alsee added a comment.Aug 23 2018, 3:42 PM

I suggest this task be closed. If necessary any current use cases can be addressed in a more narrow fashion. Per Harej, a non-default model might be created via workflow rather than modifying an existing page, or we could narrowly allow swapping Talk pages between wikitext and Flow, or admins can grant a permission by-need-and-approval (like TemplateEditor).

Anything that interacts with javascript, even indirectly, always requires the most strict scrutiny. The initially-overlooked issue of other users' js pages is bad. It's dubious why we would offer general users an option to change the model of mainspace articles, even if it is easily revertible. And we shouldn't impose a preemptive result regarding future content models. Use of content models should develop further before we consider whether generic model changing can&should be a common and appropriate activity for untrused users.

But is that still happening? If so it's a real blocker IMHO.

Edit: I'm refering to T85847#2959070.

I think the current status post https://gerrit.wikimedia.org/r/c/mediawiki/core/+/309815 (I haven't tested this recently) is that only people who can currently 'edit' the page and 'editcontentmodel' the page can turn it into a not-CSS/JS page. At that point it is publicly editable, but ResourceLoader will just ignore it and won't load it. And to convert it back to CSS/JS, you'd need to be able to edit the page under it's new content model, which means only sysops/interfaceadmin and the user themselves could convert it.

I suggest this task be closed. If necessary any current use cases can be addressed in a more narrow fashion. Per Harej, a non-default model might be created via workflow rather than modifying an existing page, or we could narrowly allow swapping Talk pages between wikitext and Flow, or admins can grant a permission by-need-and-approval (like TemplateEditor).

I'd like to continue to go forward with this, and I think this line of argumentation was addressed in T85847#2626070 and T85847#2632672.

Anything that interacts with javascript, even indirectly, always requires the most strict scrutiny. The initially-overlooked issue of other users' js pages is bad.

I believe the JavaScript/CSS issues have already been fixed, but it's been a while since I looked into this.

It's dubious why we would offer general users an option to change the model of mainspace articles, even if it is easily revertible.

I think what you're asking for is T145174: Perhaps should have a notion of titles that must use default content model.

And we shouldn't impose a preemptive result regarding future content models. Use of content models should develop further before we consider whether generic model changing can&should be a common and appropriate activity for untrused users.

The default wiki permission model works in such a way that users are generally trusted first (AGF, etc.) and then lose trust. IMO the content model system has been crippled since it's always been tied to namespaces instead of being freely changeable. which is why I'm pushing for this change.

MGChecker added a comment.EditedSep 16 2018, 3:05 PM

We should really get this done, now that TemplateStyles is deployed and it's on user level by default. It's really annoying to rely on an admin any time you want to create new template styles or change the content model of a page in your userspace. There is no reason to keep this from autoconfirmed users, especially not from security perspective. It's not really a new thing that you can vandalize wiki pages by creative means.

If it will be done, is there a way to avoid contentmodel change from something to sanitized css, using abusefilter?

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

Seems like a nice to have feature to me, but you can just change it back if abused? Changing content models is even easier to revert than page moves (because of the redirects).

No, I can't. Our community decided to allow templarestyles editing to autopatrolled users only. Ruwiki community (@Jack_who_built_the_house, pay attention) decided to allow this to engineers group or to admins. Both of us asked phabricator changes, and the tasks were declined because it can be done using abusefilter, without a need to watch the pages, or to change it back manually. If it can't any more, it's a problem. Thank you.

This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.

I'm not following why developers would be refusing to allow access to communities that have specifically reviewed and requested access for certain groups though? Do you have the phab numbers to review?

Sometimes page moves and similar actions change the content model of TemplateStyles pages to wikitext, and currently you're unable to change it back without asking a sysop, which can be kind of annoying.

If a few communities changed their permissions like that, they can decide to reduce the availability of this permission. However, I personally don't get it why template styles should have more protections then the associated templates themselves…

This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.

Sorry, I do not understand how can it help.

I'm not following why developers would be refusing to allow access to communities that have specifically reviewed and requested access for certain groups though? Do you have the phab numbers to review?

Of course, here you are: T188287, T187729. And also https://he.wikipedia.org/wiki/Special:AbuseFilter/90 and https://ru.wikipedia.org/wiki/Special:AbuseFilter/168.

wctaiwan removed a subscriber: wctaiwan.Sep 16 2018, 8:27 PM

@IKhitron ok, I must have misunderstood you , I though you wanted to allow an existing group to use the 'editcontentmodel' right and were denied.