empathy GUI has no option to get the details behind a nickname / ID

Bug #476582 reported by benste
76
This bug affects 21 people
Affects Status Importance Assigned to Milestone
Empathy
Invalid
Undecided
Unassigned
Telepathy Haze
Unknown
Medium
telepathy-haze (Ubuntu)
Triaged
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: empathy

As all of you who use IM know some times you may get spam.

Usually I could look up user details for a nick / ID to vertify that this ID (e.g. ICQ which is 9 numbers only) belongs to a specific person.

In the latest version I have NO way to lookup this user details, as this makes it impossible to dissallow users or organizing i would say this is at least medium important.

If wished I'll report upstream for on bugzillla too, but usually solutions can be found easier here :-)

ProblemType: Bug
Architecture: i386
Date: Fri Nov 6 16:23:16 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: empathy 2.28.1.1-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: empathy
Uname: Linux 2.6.31-14-generic i686

Revision history for this message
benste (benste) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Changed in empathy (Ubuntu):
importance: Undecided → Low
Revision history for this message
benste (benste) wrote :

did it ones again, it looks like empathy is chekcing the user some time after you try to add, but as you can't invoke this manually and don't know that it will come there I'll forward it upstream.

Revision history for this message
benste (benste) wrote :

Sebastien, could you change bug status to wishlist ?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for sending the bug to GNOME

Changed in empathy (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: New → Triaged
Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

Some Empathy bugs [1] [2] seem to suggest that we have to pull alias (and others contact info) from the ICQ server. Pidgin does that by exposing "Retrieve contact details" in the UI which is something we don't want to do in Empathy. So I guess haze should pull these info automatically so it always has all the info about the contacts.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=590595
[2] https://bugzilla.gnome.org/show_bug.cgi?id=602229

Revision history for this message
In , Stefan Hammer (j-4-deactivatedaccount) wrote :

Also found on Launchpad:
https://bugs.launchpad.net/empathy/+bug/474527

Empathy shows icq numbers instead of names (aliases):
"I' ve just updated my Jaunty to Karmic. I added my icq account to empathy. In my contact list there are shown almost only icq numbers instead of names (aliases). Moreover, when I try to get Contact Information i also see only number, no alias. It's quite annoying because I don't know who is who..."

Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

Reassigning since upstream forwarded this to the telepathy bug tracker.

affects: empathy (Ubuntu) → telepathy-haze (Ubuntu)
Changed in empathy:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
Changed in telepathy-haze:
status: Unknown → Confirmed
Revision history for this message
Stefan Eike (stefan.eike) wrote :

No solution?

Revision history for this message
In , Will Thompson (wjt) wrote :

I just created an ICQ account and tested this with ven, a user from #telepathy. Interesting results. From ven's side:

• haze logged from get_alias() that my user name was my UIN, but on the Empathy roster it quickly/immediately changed to my alias.
• contacts for which ven has set a custom alias show up properly; other contacts do not.

From my side:

• ven shows up on my Empathy contact list as a UIN.
• Haze's debug output shows it suppressing a system message being written to the conversation window showing "<uin> is now known as ven". There are two places in libpurple which produce that message. Following the code around, the one we're hitting ought to be emitting blist-node-aliased, but it doesn't seem to be.

More investigation needed.

Revision history for this message
In , Will Thompson (wjt) wrote :

Woo hoo!

Here's a branch that should fix this (and which tidies up connection-aliasing.c a bunch too).

Revision history for this message
In , Will Thompson (wjt) wrote :

To clarify:

The problem seems to have been that Empathy explicitly sets contacts' alias to their ID. So if the contact-specified nickname doesn't arrive fast enough — which it doesn't — the ICQ user's alias is forcibly set to their UIN, and then when their actual nickname arrives, we don't get it because we already have a user-set alias for the contact.

So this branch makes setting a contact's alias to their ID a no-op.

I'm wondering about making the alias lookup code explicitly ignore the local alias if it's the user's UIN, and try the remote nickname instead. Thoughts?

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #4)
> The problem seems to have been that Empathy explicitly sets contacts' alias to
> their ID. So if the contact-specified nickname doesn't arrive fast enough —
> which it doesn't — the ICQ user's alias is forcibly set to their UIN, and then
> when their actual nickname arrives, we don't get it because we already have a
> user-set alias for the contact.

To be honest, this sounds like a problem with Empathy? It shouldn't really do that, and it'll hurt other CMs almost equally (it looks as though the only reason we have a bug report for ICQ and not for XMPP is that UINs are worse than JIDs).

IMO, the only time that Empathy should be setting a contact's alias is when the user explicitly sets it. Adding a new contact should fetch the existing nickname with RequestAliases to populate a text box, and let the user say "yes" to it; perhaps it should even not enable the [OK] button, or not pop up the dialog, or something, until RequestAliases (maybe with a shorter-than-default timeout) has returned?

In CMs where we automatically grab nicknames and store them in the roster for performance reasons (i.e. Gabble - thanks, XMPP), it's the CM's job to do that, and Empathy shouldn't duplicate it.

When we have a distinction between user-set (or at least user-approved) aliases (Bug #14540) it'll become more important to not trample on the user-set alias, but at least you'll be able to see the remotely-set nickname in the tooltip or something and work out who it is.

Revision history for this message
In , Felix Kaser (f-kaser) wrote :

This is also a problem when you get requests from people you don't know. It happens quite often that there are spammers around and you have to look up the id on people.icq.com in order to see whats their name and alias.

There is a new on empathy for this: https://bugzilla.gnome.org/show_bug.cgi?id=625402

Changed in telepathy-haze:
importance: Unknown → Medium
Revision history for this message
Gunnar Thielebein (lorem-ipsum) wrote :

I am using ICQ through a Jabber transport (jabber.scunc.net btw.) and it was retrieving the ICQ information in the past, via Pidgin and Psi, correctly.
After switching to Empathy (2.32.1-0ubuntu1/maverick) the retrieving of additional information does not work. The "Request Contact info" spinner keeps rotating without a timeout. Please tell me if you need more information!

Changed in telepathy-haze:
importance: Medium → Unknown
Changed in telepathy-haze:
importance: Unknown → Medium
Revision history for this message
Gryffus (gryffus) wrote :

Any news on this?

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-haze/issues/27.

Changed in telepathy-haze:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.