https://bugzilla.wikimedia.org/show_bug.cgi?id=33537
Web browser: ---
Bug #: 33537
Summary: RFE: Hook to change Enotif recipient list
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Unprioritized
Component: Email
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: softw...@macfreek.nl
Classification: Unclassified
Created attachment 9810
--> https://bugzilla.wikimedia.org/attachment.cgi?id=9810
Move variable instantiation out of the actuallyNotifyOnPageChange() function
This is a request for enhancement, but it must be fixed in Mediawiki, and can
not be solved by writing an extension (actually it is a blocker for my
extension).
The core of the problem is that the function
EmailNotification::actuallyNotifyOnPageChange in UserMailer.php does three very
distinct things in one functions:
1. Initialise protected instance variables
2. Compose a list of email addresses (using the watchlist and
$wgUsersNotifiedOnAllChanges setting)
3. Send email (through the use of the compose() and sendMails() helper
functions)
This mix of functionality in a single function makes it impossible to:
1. Change the list of email addresses
2. Use the helper functions to send emails, since both compose() and
sendMails() require that the instance variables ($this->title, $this->editor,
etc.) are set, and EmailNotification::actuallyNotifyOnPageChange is the only
function that can set this.
I'm currently writing an extension that sends email notification for
unpatrolled (= not autopatrolled) changes (implementing
$wgUsersNotifiedOnUnpatrolledChanges, similar to the existing
$wgUsersNotifiedOnAllChanges). Unfortunately, the above limitations make it
impossible for me to use the EmailNotification class.
The ideal would be if there is a hook that allows alteration of the list of
recipients (as hinted on by r44960), but failing that, please at least move the
initialisation of protected variables to its own function (e.g. using the
attached patch)
Notes:
Note 1: The patch removes the unused $to and $user instances variables, since
they are not used anywhere.
Note 2: I'm not sure why this class does not have a __construct() function, but
there may have design reasons I'm not aware of. For that reason, I did not
change any behaviour and used construct() instead of __construct() in the
patch.
Note 3: Adding a hook function is the best solution because of flexibility and
performance reasons (composeCommonMailtext() would only be called once; and the
JobQueue would automatically be used if $wgEnotifUseJobQ is set). However, I'm
not very familiar how MediaWiki uses hooks, so I rather have some feedback on
that from experienced developers.
Note 4: I'm note sure what the best place for the hook function is. My intended
extension needs access to the (auto)patrol flag of the RecentChange, but this
does not seem available to the EmailNotification class. Again, it is highly
desirable to make a first split between the function of selecting email
addresses on one hand, and sending the actual mail on the other hand.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
