Last modified: 2009-06-06 06:31:12 UTC
If email functions are not enabled on a wiki, it is wrong to still present this option.
Found that string also in includes/api/ApiBlock.php:148: 'noemail' => 'Prevent user from sending e-mail thr includes/ProtectionForm.php:116: // Prevent users from setting levels that languages/messages/MessagesEn.php:2636:'ipbemailban' => 'Prevent user from sending e but I didn't check further.
(In reply to comment #1) > Found that string also in > includes/api/ApiBlock.php:148: 'noemail' => 'Prevent > user from sending e-mail thr > includes/ProtectionForm.php:116: // Prevent users > from setting levels that > languages/messages/MessagesEn.php:2636:'ipbemailban' => > 'Prevent user from sending e > but I didn't check further. > You should probably be grepping the message name ('ipbemailban') instead, as these hits are mostly irrelevant.
Hello, I am trying to reproduce this bug. Can you provide me with the information regarding which page and part of MediaWiki where the checkbox appears.
Sorry my mistake. I did not notice the blocking component on the bug.
Created attachment 6121 [details] Patch that hides block email option if user to user email is disabled I have created a patch to the block page that does not show the Block user from sending email option if $wgEnableUserEmail is set to false in LocalSettings.php. As this block option is for disabling a user sending email to other users, i have not added checking for $wgEnableEnable to be false.
The patch doesn't do global $wgEnableUserEmail;
Created attachment 6122 [details] Version 2 of Patch with global $wgEnableUserEmail I have fixed the problem with it not doing global $wgEnableUserEmail in the patch i submitted previously.
Doen in r50635
Ive removed the need-review keyword, as its been resolved.
As noted in CR on r50635, this is duplicated code -- a check for three different items is now duplicated into at least three places, making it likely that they'll get out of sync in future development. This should be refactored into a single function which can be called and updated consistently in the future.
This has been noted as fixed in r50922 and r50774. I have closed the bug. Reopen it it is not fixed.