Implement some restriction on who can deliver cross-wiki messages
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	Legoktm
	Oct 4 2013, 5:05 AM

Description

See rationale on bug 52723 comment 37, counter argument on comment 39, response to that on comment 48.

This feature was removed in https://gerrit.wikimedia.org/r/#/c/78047/.

There are two different ways we can do this:

Add a new user-right called 'massmessage-global', and require users sending notifications cross-wiki have this right.

Add a config switch ($wgAllowCrossWikiMessages) that allows that wiki to send messages to another wiki. So this would be turned on for meta, and any user on meta with 'massmessage' would be able to send cross-wiki.

Personally I favor the user-right implementation since it gives more control and flexibility, but at the same time, it adds yet another user right >.>

Next question: what should happen if a user attempts to send a message to a list with cross-wiki targets but does not have the proper permissions (or it is disabled on the wiki)

The entire submission is rejected until the spamlist has those entries removed

A warning is given to the user and those cross-wiki targets are dropped from the list.

If we use the config switch, the parser function could reject any target that is not on the current site with the red error message we have for invalid input.

Version: unspecified
Severity: normal

Details

Reference: bz54954

Related Objects
Search...

Status	Subtype	Assigned	Task
Open	Feature	None	T66475 Make crosswiki bits and pieces truly global (tracking)
Resolved		None	T37306 Global (to a wiki farm or family) message delivery (thoughts)
Resolved		Reedy	T54723 Review and deploy MassMessage extension to Wikimedia wikis
Resolved		None	T56954 Implement some restriction on who can deliver cross-wiki messages

Event Timeline

• bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:39 AM

• bzimport added a project: MassMessage.

• bzimport set Reference to bz54954.

• bzimport added a subscriber: Unknown Object (MLST).

Legoktm created this task.Oct 4 2013, 5:05 AM

I'd vote for the feature flag, because it is simplest for now and makes it easy to reject invalid input for the distribution lists.

Change 87613 had a related patch set uploaded by Legoktm:
Add a config flag, $wgAllowGlobalMessaging, to allow global messaging

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

I'm rather uncomfortable with fully open cross-wiki messaging as well,
for all the reasons outlined at bug 52723. I think the config switch
would be better here (long-term as well), both for simplicity and
because it would explicitly mark the "central" wiki(s), making the
source of the messages obvious. Both solutions are sound, though.

Whichever we settle on, we should not drop entries silently – either
reject the entire spamlist until the message submitter fixes it, or
display a warning message like the ones for interwiki links or unclosed
tags before submission. I'd lean towards rejecting here to avoid stupid
mistakes.

(In reply to comment #3)

Whichever we settle on, we should not drop entries silently – either
reject the entire spamlist until the message submitter fixes it, or
display a warning message like the ones for interwiki links or unclosed
tags before submission. I'd lean towards rejecting here to avoid stupid
mistakes.

My current patch is that if a user adds a cross-wiki target on a non-crosswiki wiki, instead of the link to the target that is generated, a red error message shows up (same as an error like [[testwiki:MM/3]]). The user won't see anything on the actual special page though.

(In reply to comment #4)

My current patch is that if a user adds a cross-wiki target on a
non-crosswiki
wiki, instead of the link to the target that is generated, a red error
message
shows up (same as an error like [[testwiki:MM/3]]). The user won't see
anything
on the actual special page though.

This is the best way, IMHO: you can correct the list beforehand and others can easily see who was excluded. Moreover, in the future I think the parser function can be extended in other interesting ways.

Change 87613 merged by jenkins-bot:
Add $wgAllowGlobalMessaging to allow global messaging