Created an RFC per @eprodromou's comment at T226926#5615258

This doesn't seem to be strategic, cross-cutting, or hard to undo, so it doesn't need an RFC. It can still go through the RFC process if that would be helpful to gather input.

This may have Security implications though: while having the javascript content model should by itself not allow the content to be executed in the browser, we should make doubly sure that this cannot possibly happen. For instance, we'd have to make sure that it would be impossible to link to a raw representation of the javascript code that might be executed by the browser. Pinging the Security-Team for visibility.

Per Daniel, this seems fine. Improvement in granularity of permissions is a good thing. Feel free to loop us in again if CR is needed when appropriate, but not something we'll probably work on (and it looks like DannyS712 is planning on anyway)

In T248294#5995158, @Reedy wrote:

Per Daniel, this seems fine. Improvement in granularity of permissions is a good thing. Feel free to loop us in again if CR is needed when appropriate, but not something we'll probably work on (and it looks like DannyS712 is planning on anyway)

https://www.mediawiki.org/wiki/Security/SOP/Security_Readiness_Reviews

As an additional use case I literally just ran into - You can only test templatestyles in your user-space (sanitized-css content model) on enwiki if you're an admin, which is a giant pain.

Pages with the javascript model should (and do, I think) require their own user right on top of whatever basic right would be required for creating non-default-content-model pages; I don't think there's any security issue there.

That said I'm not sure there would be much use for a one-size-fits-all right that can be given to non-admins; that should be handled per use case.

EditPage makes two checks (in internalAttemptSave), PermissionManager::userHasRight( $user, 'editcontentmodel' ) and PermissionManager::userCan( 'editcontentmodel', $user, $titleWithNewContentModel ). The latter can easily be special-cased for non-existing pages via the userCan hook, the former is a problem and should probably be replaced with PermissionManager::userCan( 'editcontentmodel', $user, $title ).

In T248294#6000958, @Bawolff wrote:

As an additional use case I literally just ran into - You can only test templatestyles in your user-space (sanitized-css content model) on enwiki if you're an admin, which is a giant pain.

Isn't that what the template sandbox is for? You can't test Scribunto modules etc. in your userspace either, but that's not really what userspaces are for. Articles are special, because they tend to be created by new users who can use the extra UX and social protection the userspace gives, and gadgets are also special because they are potentially dangerous and trust in the author matters a lot, but in general just use template, module etc. sandboxes.

(Related: T177027: Should we allow sanitized-css (TemplateStyles) content under titles where it is not the default content model?)

Removing RFC tag, since there doesn't seem to be strong interest in putting this through the process, and this doesn't tick any of the boxes that would require an RFC.

In T226926#5615258, @eprodromou wrote:

This seems like a good conversation for TechCom to get into. Managing how and when users can create pages with different content models is probably not something we should do piecemeal, but as part of a more holistic approach. Can you turn this into an RFC for discussion?

So is this approved from a product standpoint?

In T248294#6019448, @DannyS712 wrote:

So is this approved from a product standpoint?

My reading of the situation is: TechCom has no objections, the security team has no objections, but feature ownership from a product perspective is unclear. My best guess would be that this would be decided by the Editing-team.

Tagging Editing-team for approval

As with T92795, I don't think this should be a special user-right per-se, just that the workflows should be fixed to automatically do this in appropriate cases. Just as if someone creates a template:x/style.css it is in s-css; they should be able to use the createmailinglist tool to create a page in MMS style.

In T248294#6078941, @Xaosflux wrote:

As with T92795, I don't think this should be a special user-right per-se, just that the workflows should be fixed to automatically do this in appropriate cases. Just as if someone creates a template:x/style.css it is in s-css; they should be able to use the createmailinglist tool to create a page in MMS style.

Well, https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MassMessage/+/513512/ has a -1 for changing the permission needed to create MMS lists

Maybe, rather than a new permission for that, something like $wgCustomModelProtection[] which allows requiring a specific right for certain models (presumably those that could be sensitive, most models shouldn't need that), rather than a one-right fits all approach.