Author: happy.melon.wiki
Description:
If email functions are not enabled on a wiki, it is wrong to still present this option.
Version: 1.15.x
Severity: minor
• bzimport | |
Apr 21 2009, 8:43 PM |
F5653: bug18549v2.patch | |
Nov 21 2014, 10:35 PM |
Author: happy.melon.wiki
Description:
If email functions are not enabled on a wiki, it is wrong to still present this option.
Version: 1.15.x
Severity: minor
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
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:
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.