When did MassMessage ContentHandler development finish?

Weren't there database schema changes needed to support MassMessage ContentHandler? When were those finished?

I'm just trying to get an idea of how long it's been to get this feature enabled.

mm-ch was finished and deployed to testwiki in August/September last year. The schema changes happened over a few months and finished in January (T51193).

I'm not sure that I understand why T92794 is a blocker. How is MassMessage using ContentHandler today?

During GSoC 2014, I worked on a project (https://www.mediawiki.org/wiki/Extension:MassMessage/Page_input_list_improvements) that added a ContentHandler-based system for managing delivery lists. It's unusable on Wikimedia wikis at the moment since most users don't have the user right needed to create delivery lists.

In T92795#1120499, @RobLa-WMF wrote:

I'm not sure that I understand why T92794 is a blocker. How is MassMessage using ContentHandler today?

https://test.wikipedia.org/wiki/Yay_mm-ch! is an example of mm-ch. It's not actively advertised or used at all due to T92794. If you go to [[Special:CreateMassMessageList]] on any WMF wiki, you'll get a permission denied error because of the editcontentmodel right.

Thanks for the quick response @wctaiwan. 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. This avoids the usability problems associated with being able to arbitrarily change the content type for a given page. Was that approach considered? Also, is this new system getting any use at all yet, or is even initial deployment of this blocked on resolution of this issue?

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.