Page MenuHomePhabricator

Allow each log action to set whether to send email notification and with which subject/body
Closed, ResolvedPublic

Description

+++ This bug was initially created as a clone of Bug #42457 +++

This, together with a bunch of changes in the extensions, would be – I guess – the most complete fix for bug 14901.

(Quoting from bug 14901 comment #63)

"We could add handling for protect/unprotect/right, but this would not solve
the fundamental of this issue. Any new log action about an article attempts to
send an email, it would be really hard to catch all log-actions since any
extensions could add a new log-action and it's not appropriate to handle them
inside the notification code.

Instead, I think we should alter the log to include a send_email param in
log_param which checks whether to send emails and leave the email subject/body
definition to extensions or the code that creates the log. This would require
some time and go far beyond 20% time.

I'd call this an enhancement, while bug T44457 is the remaining bug to be fixed (probably less painful than this request).

This might even be /too/ complete a solution and overlap with Echo work on core: cc'ing Andrew to be safe.

Details

Reference
bz42458

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:59 AM
bzimport added a project: MediaWiki-Email.
bzimport set Reference to bz42458.
bzimport added a subscriber: Unknown Object (MLST).

It is not possible to suppress log notifications emails or alter their content with current hooks in core.

Change 132600 had a related patch set uploaded by Nemo bis:
Extend AbortEmailNotification hook to access log type etc.

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

Change 132600 merged by jenkins-bot:
Extend AbortEmailNotification hook to access log type etc.

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

Approved by IAlex. :) Hopefully that's enough for the "whether to send an email" side, but changing content is tricky: how can we do that, by making enotif_body more modular perhaps? (As was done in part for bug 14901.)

matmarex added a subscriber: matmarex.

This is already possible, and I think it may have even already been possible when this task was filed in 2012.

However, it seems that no extension actually implements it (at least none in our repositories).

These days, and maybe even back in 2012, it's probably better to use Echo for your email notifications. It's more flexible for developers, more configurable for users, and the notifications look nicer than the built-in MediaWiki ones. https://www.mediawiki.org/wiki/Extension:Echo/Creating_a_new_notification_type#Walkthrough:_Creating_a_new_notification_type


But just for reference, if you wanted to customize the built-in MediaWiki watchlist email notifications, here's how you'd do it.

Prerequisite: Your action must generate log entries, associated with a watchable page title, and published to recent changes. See documentation here on how to implement that: https://www.mediawiki.org/wiki/Manual:Logging_to_Special:Log

Anything published to recent changes generates email notifications too by default. If you want not to send email notifications, use the AbortEmailNotification hook to prevent it:

Hooks.php
public function onAbortEmailNotification( $editor, $title, $rc ) {
	if ( $rc->getAttribute( 'rc_log_type' ) === 'example' ) {
		return false;
	}
}

In order to customize the message subject/body, you must first use the UpdateUserMailerFormattedPageStatus hook to register a new kind of notification:

Hooks.php
public function onUpdateUserMailerFormattedPageStatus( &$formattedPageStatus ) {
	$formattedPageStatus[] = 'exampled';
}

That allows you to use the RecentChange_save hook (or the AbortEmailNotification hook, if you're already using it) to define your notification for your recent changes entries:

Hooks.php
public function onRecentChange_save( $rc ) {
	if ( $rc->getAttribute( 'rc_log_type' ) === 'example' ) {
		$rc->mExtra['pageStatus'] = 'exampled';
	}
}

The last thing to do is defining the localisation messages for your page status chosen above:

en.json
"enotif_subject_exampled": "{{SITENAME}} page $1 has been {{GENDER:$2|exampled}} by $2",
"enotif_body_intro_exampled": "The {{SITENAME}} page $1 has been {{GENDER:$2|exampled}} on $PAGEEDITDATE by $2, see $3.",

Once again: you probably shouldn't do it this way. (Other than using the AbortEmailNotification hook to avoid duplicating your fancy Echo notification.) No one has bothered to figure it out in 10 years, because Echo is better. Do this instead: https://www.mediawiki.org/wiki/Extension:Echo/Creating_a_new_notification_type#Walkthrough:_Creating_a_new_notification_type