Developers:

how do you think about this change in the user interface

• dropping the display "e-mail this user", if emailing is not possible to that user

Wouldn't it be better to show the link, but to indicate (with "grey" color ?),
that it is not possible to mail ?

(In reply to comment #0)

If someone wants to send an e-mail to a user, he clicks onto that link in the
navi-bar.

The Wikis are currently slow and then, after a while, you see probably something
like "This user has not specified a valid e-mail address, or has chosen not to
receive e-mail from other users."

I propose to either

a) suppress the display of the link "e-mail this user" if this user has no email
stored or has disabled to receive mails

or to

b) indicate "feature unavailable" by another kind of indication.

Couldn't this be lower the traffic a little bit ? In any sense, I often was
suprised, that the link was shown, even when I could not send an e-mail to a
user, because he hasn't indicated an address.

Other related bugzilla, not depending or blocking:

1. http://bugzilla.wikipedia.org/show_bug.cgi?id=1226 (negate "disable mail"

option box logic GUI)

2. http://bugzilla.wikipedia.org/show_bug.cgi?id=1133 (send optionally a "CC"

back to sender of EmailUser)

(In reply to comment #1)

Wouldn't it be better to show the link, but to indicate (with "grey" color ?),
that it is not possible to mail ? If someone wants to send an e-mail to a

user, he clicks onto that link in the

navi-bar.

I propose to either

a) suppress the display of the link "e-mail this user" if this user has no email
stored or has disabled to receive mails

ADDED:
If the visiting user (potential sender) is not logged-in or has no email stored,
than the link text must also not be shown, as is proposed by older see
http://bugzilla.wikipedia.org/show_bug.cgi?id=356 (added below).

or to

b) indicate "feature unavailable" by another kind of indication.

Couldn't this be lower the traffic a little bit ? In any sense, I often was
suprised, that the link was shown, even when I could not send an e-mail to a
user, because he hasn't indicated an address.

Other related bugzilla, not depending or blocking:

1. http://bugzilla.wikipedia.org/show_bug.cgi?id=1226 (negate "disable mail"

option box logic GUI)

2. http://bugzilla.wikipedia.org/show_bug.cgi?id=1133 (send optionally a "CC"

back to sender of EmailUser)

3. http://bugzilla.wikipedia.org/show_bug.cgi?id=356 ("E-mail this user" errors

not labeled well) +++THIS ONE ADDED TO THE LIST

Tom Gries wrote in Additional Comment #1:

Wouldn't it be better to show the link, but to indicate (with "grey" color ?),
that it is not possible to mail ?

It would be better to show the ''text'', but it should not be a ''link''.
Even a red link would serve no purpose, so why tempt people to click it?
(Although I think that whether to show the text is less important
than to NOT show the link.)

It's worth noting that this link does serve a purpose currently:
It allows one to see, at a glance, that a user with no user page exists.
That is, suppose that [[User:Foo]] exists but has no user page,
while nobody has ever signed up as [[User:Bar]] to begin with.
If you go to their user pages, there is little sign of this difference,
and you might be led to think that [[User:Foo]] doesn't exist either.
But in fact, there will be an "E-mail this user" link for [[User:Foo]],
while no such link exists for [[User:Bar]].

This is not enough reason to avoid the enhancement of course.
There are two remedies: replacing the link with (grey) text,
and the "User contributions" link, which has the same behaviour.
But it's something to be aware of.

• [[w:en:User:Toby Bartels]]

• Bug 4516 has been marked as a duplicate of this bug. ***

robchur wrote:

You'd still have to check to see whether said user opts to/can receive email, so
performance-wise, it's not a massive difference. From the user interface point
of view, however, it makes sense not to show the text, linked or not, if the
feature's not available.

Just a note: if implementing this, don't forget to touch & purge the user page when the user's
prefs or mail confirmation state changes.

gangleri wrote:

Hallo!

In my opinion the user interface for user A regarding "E-mail this user" at user
B's user and user talk page should depend on
a) has user A specified [[MediaWiki:Allowemail]] ?
b) has user A performed [[MediaWiki:Emailconfirmlink]] ?
c) has user B specified [[MediaWiki:Allowemail]] ?
d) has user B performed [[MediaWiki:Emailconfirmlink]] ?

The question is what actions should be performed / what links should be
generated. A grey link will not guide users. Probably displaying the specific
details with links to [[special:Preferences]], [[special:Confirmemail]] ?)
together with "&returnto=foo" would be a better choice.

best regards reinhardt [[user:gangleri]]

gangleri wrote:

(In reply to comment #7)

... d) has user B performed [[MediaWiki:Emailconfirmlink]] ?

implies
e) has user A specified an email address ?
f) has user B specified an email address ?

Completely hides the emailuser link if it wouldn't work

It seems to make the most sense to just hide the link if it won't work, rather than making it plaintext.

attachment emailuser_hide.patch ignored as obsolete

I think I'd recommend moving the $wgEnableUserEmail check into User::canSendEmail() to simplify things in general. The $wgUser->isLoggedIn() checks is also redundant; an anonymous user won't pass that test. :)

The user page cache invalidation in User::saveSettings will do the job for when someone enables/disables the email option... and it should also do the job for other stuff. Excellent. :D

(In reply to comment #10)

Excellent. :D

Even when considering that I proposed this ?

Revised version

(In reply to comment #10)

The user page cache invalidation in User::saveSettings will do the job for when
someone enables/disables the email option... and it should also do the job for
other stuff. Excellent. :D

I had a small progasm when I got the cache invalidation right.

Attached:

/me hugs Tom Gries :)

Emufarmers -- applied in r42179 with one-char fix (missing $ on one of the var checks).