Last modified: 2009-06-06 06:31:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 18549 - "Prevent user from sending email" checkbox still appears even if email is disabled
"Prevent user from sending email" checkbox still appears even if email is dis...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
1.15.x
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch-reviewed
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-21 20:43 UTC by Happy-melon
Modified: 2009-06-06 06:31 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch that hides block email option if user to user email is disabled (536 bytes, patch)
2009-05-15 11:29 UTC, Karun
Details
Version 2 of Patch with global $wgEnableUserEmail (796 bytes, patch)
2009-05-15 11:54 UTC, Karun
Details

Description Happy-melon 2009-04-21 20:43:15 UTC
If email functions are not enabled on a wiki, it is wrong to still present this option.
Comment 1 Dan Jacobson 2009-05-15 10:50:34 UTC
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.
Comment 2 Roan Kattouw 2009-05-15 11:06:04 UTC
(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.
Comment 3 Karun 2009-05-15 11:07:36 UTC
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.
Comment 4 Karun 2009-05-15 11:09:00 UTC
Sorry my mistake. I did not notice the blocking component on the bug.
Comment 5 Karun 2009-05-15 11:29:16 UTC
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.
Comment 6 Roan Kattouw 2009-05-15 11:35:06 UTC
The patch doesn't do global $wgEnableUserEmail;
Comment 7 Karun 2009-05-15 11:54:16 UTC
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.
Comment 8 Chad H. 2009-05-15 17:08:49 UTC
Doen in r50635
Comment 9 Karun 2009-05-15 21:36:04 UTC
Ive removed the need-review keyword, as its been resolved.
Comment 10 Brion Vibber 2009-05-18 19:04:51 UTC
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.
Comment 11 Karun 2009-06-06 06:31:12 UTC
This has been noted as fixed in r50922 and r50774.
I have closed the bug. Reopen it it is not fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links