In T92795#1120504, @RobLa-WMF wrote:

One fairly typical way of handling this is to create a new namespace for holding configs, and then make that namespace default to the ContentHandler type for MassMessage.

I don't think this is a good idea. In many cases, it would be more logical to have a delivery list as a subpage. (For example, the Signpost's subscription list is located at Wikipedia:Wikipedia Signpost/Tools/Spamlist.)

This avoids the usability problems associated with being able to arbitrarily change the content type for a given page.

I'm not sure what you mean here by usability. As far as I know, there is no exposed UI for changing the content model. If you mean there could be adverse effects from arbitrarily modifying the content model, the security-related ones are why we have the user right in the first place (T72901), and the other ones could probably be dealt with as we deal with unconstructive edits in general.

It might be worth considering whether to disallow changing a page's content model after creation, but tying the content model to the namespace probably too inflexible (e.g. consider wikitext talk pages and Flow boards coexisting).

Also, is this new system getting any use at all yet, or is even initial deployment of this blocked on resolution of this issue?

It's never actually been usable, since even sysops don't have the user right by default. (Legoktm created a patch a few hours ago to give it to sysops: https://gerrit.wikimedia.org/r/#/c/196981/) Anyone can go to e.g. http://en.wikipedia.org/wiki/Special:CreateMassMessageList -- but clicking Submit gives a permission error.

In T92795#1120542, @wctaiwan wrote:

I'm not sure what you mean here by usability. As far as I know, there is no exposed UI for changing the content model. If you mean there could be adverse effects from arbitrarily modifying the content model, the security-related ones are why we have the user right in the first place (T72901), and the other ones could probably be dealt with as we deal with unconstructive edits in general.

The way we deal with unconstructive edits in general is allow anyone (even people who can't program a bot) the ability to easily revert a disruptive action. Without addressing the blockers to T85847 (such as T72592), only someone conversant with the API will be able fix things up after a vandal swoops through.

On many (all?) wikis, we have namespaces where allowing experimentation would be useful. For example, riffing off of your Signpost example, it seems perfectly reasonable to allow the MassMessage content model in enwiki's Wikipedia: namespace. However, it's hard to imagine what benefit there would be in allowing it in enwiki's main namespace.

I get your point about not wanting to insist on a brand new namespace for MassMessage.

In T92795#1120472, @wctaiwan wrote:

mm-ch was finished and deployed to testwiki in August/September last year.

Is it documented in some Extension, Manual or Help namespace page on mediawiki.org?

In T92795#1120973, @Nemo_bis wrote:

Is it documented in some Extension, Manual or Help namespace page on mediawiki.org?

https://www.mediawiki.org/wiki/Help:Extension:MassMessage#ContentHandler_delivery_lists_.28MediaWiki_1.24_or_later.29

So... what else is needed here? Is T85847 the only outstanding issue?

I think this task is now resolved.

I think we should aim for allowing anyone, not just sysops, to create delivery lists.

@wctaiwan as an immediate workaround, you can do what we did on enwiki: create a batch of empty shells.

From discussion on T202597 -

Would it be feasible to change the 'Special:CreateMassMessageList' permissions checking from 'editcontentmodel' to 'massmessage' ? In general we allow the creation of non-wikitext pages in special workflows already, just not this one.

Optionally, remove checking for 'editcontentmodel' access during 'Special:CreateMassMessageList' operations in general.

I agree that users with massmessage rights should be able to create such pages, but a think permissions should be checked before allowing creation; it makes sense for non privileged users to create template styles or modules, but not massmessagelists.

Change 513512 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/extensions/MassMessage@master] Change right required to create MassMessage lists from "editcontentmodel" to "massmessage".

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

@DannyS712, would "editcontentmodel" *OR* "massmessage" work even better here (I haven't thought about this in a while) - since we don't know how some downstream projects may configure their roles.

@Xaosflux I don't think that is possible, based on my understanding of the mediawiki/core/includes/specialpage/SpecialPage.php - special pages are restricted by specific user rights: '@param string $restriction User right required, e.g. "block" or "delete"', and so you can't set multiple options.

OK, no worries!

@Vogone In response to your -1 - currently, only users with the "editcontentmodel" right can create new mass message lists, though anyone can edit them to take advantage of the formatting option. This would change the user right needed to create new lists to just be massmessage, so that mass message senders can create their own lists. You will still be able to use the lists without that right.

In T92795#5245358, @DannyS712 wrote:

only users with the "editcontentmodel" right can create new mass message lists

This is exactly the problem I was addressing.

Well, currently, there are users who can send mass messages but not create new ones. What about granting mass message senders editcontentmodel rights?

@DannyS712 that would be a simple config request, but the point of this request was to avoid adding editcontentmodel to more people
@Vogone we currently support many workflows to create pages in non-wikitext (e.g. creating css pages, js pages) and I'm looking at expanding just this one workflow, do you see an issue with the concept?

In T92795#5352317, @DannyS712 wrote:

The gerrit patch was objected to by @Vogone, who hasn't responded yet to Xaosflux's question above

As far as I see, the patch also has another issue, it still checks for 'editcontentmodel' further down in the code.

In T92795#5245581, @Xaosflux wrote:

@Vogone we currently support many workflows to create pages in non-wikitext (e.g. creating css pages, js pages) and I'm looking at expanding just this one workflow, do you see an issue with the concept?

I don't, but please let us not expand this by adding yet another arbitrary restriction. I have heard no compelling argument yet why the possibility to create pages using the MassMessage content model should be restricted at all. I would therefore not object to a change removing this permission check altogether.

In T92795#4528842, @Xaosflux wrote:

From discussion on T202597 -

Optionally, remove checking for 'editcontentmodel' access during 'Special:CreateMassMessageList' operations in general.

This would be in line with your earlier proposal.

In T92795#5225092, @Xaosflux wrote:

@DannyS712, would "editcontentmodel" *OR* "massmessage" work even better here (I haven't thought about this in a while) - since we don't know how some downstream projects may configure their roles.

This is possible and the code also makes use of it. Currently, users are required to hold all of 'edit', 'create' and 'editcontentmodel' user rights in order to create a MassMessage delivery list. However, I do not support the proposed solution here.

So this is still stalled on idealistic concerns? @Vogone "I believe this restriction is harmful. It forbids users requesting a mass message delivery for their project to take advantage of this formatting option." ? My suggestion was that people that can send mass messages should be allowed to create mass message lists, and that is an improvement over the current state. How is making it incrementally better worse off then just blocking action? Additionally, any project could just add the editcontentmodel right to the 'users' group if they really wanted anyone to be able to just edit any content model. I'm even open to making a permission for Special:CreateMassMessageList, and a project could give it to mass-message-senders, or even 'users' if they really wanted to.

In T92795#6079008, @Xaosflux wrote:

So this is still stalled on idealistic concerns? @Vogone "I believe this restriction is harmful. It forbids users requesting a mass message delivery for their project to take advantage of this formatting option." ? My suggestion was that people that can send mass messages should be allowed to create mass message lists, and that is an improvement over the current state. How is making it incrementally better worse off then just blocking action? Additionally, any project could just add the editcontentmodel right to the 'users' group if they really wanted anyone to be able to just edit any content model. I'm even open to making a permission for Special:CreateMassMessageList, and a project could give it to mass-message-senders, or even 'users' if they really wanted to.

I would not say this is 'stalled on idealistic concerns'. Rather there is a proprosed solution that I objected to (without further response), which additionally has (I think) an implementation issue as outlined in my previous comment right above yours–another concern nobody reacted to, yet.

Change 513512 abandoned by DannyS712:
Change right required to create MassMessage lists from "editcontentmodel" to "massmessage".

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

DannyS712's patch above, allowing folks with the massmessage permission to use Special:CreateMassMessageList as a workaround to them not being able to edit the content model of pages, looked like a simple and good solution.

The -1 puzzles me a bit. Seems to me like that patch is an incremental improvement since it loosens who can use Special:CreateMassMessageList, but the reasoning for the -1 was "not loose enough".

Would there be support for me to take over that patch?

Related: https://en.wikipedia.org/wiki/Wikipedia_talk:Mass_message_senders#Letting_folks_with_MMS_perm_also_create_MMS_lists

We are intentionally letting perfect obstruct the good because we want to push T85847: Grant editcontentmodel right to all logged in users instead instead of inventing yet another workaround for it.

But the community, on the English Wikipedia at least, clearly doesn't want that.

In T92795#9036584, @Pppery wrote:

But the community, on the English Wikipedia at least, clearly doesn't want that.

Where has community consensus said this? Right now, you are the only opposer on the proposal.

In T92795#9039718, @Illusion_Flame wrote:

In T92795#9036584, @Pppery wrote:

But the community, on the English Wikipedia at least, clearly doesn't want that.

Where has community consensus said this? Right now, you are the only opposer on the proposal.

If you mean on T85847, I know I opposed that one as well. I'm all for making Special:CreateMassMessageList work if the user has massmessage access though.

In T92795#9039726, @Xaosflux wrote:

In T92795#9039718, @Illusion_Flame wrote:

In T92795#9036584, @Pppery wrote:

But the community, on the English Wikipedia at least, clearly doesn't want that.

Where has community consensus said this? Right now, you are the only opposer on the proposal.

If you mean on T85847, I know I opposed that one as well. I'm all for making Special:CreateMassMessageList work if the user has massmessage access though.

No, I was referring to this ticket, which as you said, allowing massmessage senders to acccess Special:CreateMMList

"that" in my comment above was referring to Legoktm's "push T85847: Grant editcontentmodel right to all logged in users". I happen to dislike this ticket too, just because I think the permission model would be logically cleaner if editcontentmodel was the only way to make a page have a nonstandard content model, but I know my opinion is a fringe minority.

Change #1035858 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/MassMessage@master] Allow users with massmessage right to create delivery lists

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

Change #1043060 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

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

Change #1043060 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

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

I think SpecialPages creating pages should decide *themselves* if the editcontentmodel right should be honored, not MediaWiki core.

Special:CreateMassMessageList shouldn't rely on the user having the editcontentmodel right, but maybe the edit and/or createpage rights. Since Special:CreateMassMessageList creates a new page, wouldn't it make more sense to check for createpage rights instead?

In T92795#9961318, @Ciencia_Al_Poder wrote:

Change #1043060 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

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

I think SpecialPages creating pages should decide *themselves* if the editcontentmodel right should be honored, not MediaWiki core.

Ideally yes, but it's almost impossible in today's MediaWiki architecture. Even just preparing to make an edit is a complex process that involves checking permissions, ip blocks, rate limits, unicode compatibility, page protections (including cascading ones), and other restrictions added by extensions (spam/title blacklists, abuse filters, captchas). Extensions do not try to do all (or any) of that by themself – they just rely on MediaWiki core. There's no way to tell core to "perform all other checks but skip the editcontentmodel right check".

That is, until someone rewrites EditPage. It's marked with Surgeon General's Warning: prolonged exposure to this class is known to cause headaches, which may be fatal so I wouldn't hold my breath.

El T92795#10100600, @SD0001 escribió:

Ideally yes, but it's almost impossible in today's MediaWiki architecture. Even just preparing to make an edit is a complex process that involves checking permissions, ip blocks, rate limits, unicode compatibility, page protections (including cascading ones), and other restrictions added by extensions (spam/title blacklists, abuse filters, captchas). Extensions do not try to do all (or any) of that by themself – they just rely on MediaWiki core. There's no way to tell core to "perform all other checks but skip the editcontentmodel right check".

That is, until someone rewrites EditPage. It's marked with Surgeon General's Warning: prolonged exposure to this class is known to cause headaches, which may be fatal so I wouldn't hold my breath.

I can clearly see explicit permissions checks on the special page itself.

On SpecialCreateMassMessageList.php I see:

	public function __construct() {
		parent::__construct( 'CreateMassMessageList', 'editcontentmodel' );
	}

Removing the 'editcontentmodel' right from there should lift the first permission error when visiting the page.

Then there's another explicit permission check on the onSubmit method that can be removed:

		} elseif ( !$pm->userCan( 'edit', $this->getUser(), $title ) ||
			!$pm->userCan( 'editcontentmodel', $this->getUser(), $title )
		) {
			return Status::newFatal( 'massmessage-create-nopermission' );
		}

Looking at how it's doing the edit, it's calling MassMessageListContentHandler::edit, which is doing an internal api call to edit the page. So yes, those explicit permission checks seem to be added to have a more nice error message to the user when it fails.

However, editing a page is not that hard. If you look at maintenance/edit.php, it's pretty simple:

$page = $this->getServiceContainer()->getWikiPageFactory()->newFromTitle( $title );
// TODO: Set the desired content model
$content = ContentHandler::makeContent( $text, $title );
$updater = $page->newPageUpdater( $user );
$updater->setContent( SlotRecord::MAIN, $content );
$updater->saveRevision( CommentStoreComment::newUnsavedComment( $summary ), $flags );

I don't know why MassMessage devs decided to use the internal api route, probably for a more stable interface, but by just modifying the extension itself the problem can be solved without skipping the check for all pages, which can be potentially abused in unforeseen ways.

The fact that it's so easy to bypass permissions like that is scary in its own way.

In T92795#10100842, @Ciencia_Al_Poder wrote:

However, editing a page is not that hard. If you look at maintenance/edit.php, it's pretty simple:

It looks simple because that method does NOT perform any of the checks that I mentioned. In other words, it will allow a even blocked IP to create an MMS list under a salted or blacklisted title.

It's fine in a maintenance script for use by trusted sysadmins, not for anything else.

I don't know why MassMessage devs decided to use the internal api route,

They decided to use it because there isn't any other route?

Change #1043060 abandoned by SD0001:

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

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

Change #1035858 abandoned by SD0001:

[mediawiki/extensions/MassMessage@master] Allow users with massmessage right to create delivery lists

Reason:

not feasible without controversial changes in core

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

I now think T85847 is the best way to resolve this.

How exactly does one "create ContentHandler delivery lists?" - can this be added to the task description? It's very vague.

In T92795#11591421, @Bugreporter2 wrote:

How exactly does one "create ContentHandler delivery lists?" - can this be added to the task description? It's very vague.

Using Special:CreateMassMessageList – but mass message senders without admin permissions cannot use that page.