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.

karun.84 wrote:

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.

karun.84 wrote:

Sorry my mistake. I did not notice the blocking component on the bug.

karun.84 wrote:

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.

attachment bug18549.patch ignored as obsolete

The patch doesn't do global $wgEnableUserEmail;

karun.84 wrote:

Version 2 of Patch with global $wgEnableUserEmail

I have fixed the problem with it not doing global $wgEnableUserEmail in the patch i submitted previously.

Attached:

Doen in r50635

karun.84 wrote:

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.

karun.84 wrote:

This has been noted as fixed in r50922 and r50774.
I have closed the bug. Reopen it it is not fixed.