Bug 25157 - ICQ nicknames get clobbered by Empathy setting the UIN as the Alias.
Summary: ICQ nicknames get clobbered by Empathy setting the UIN as the Alias.
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: haze (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/wj...
Whiteboard:
Keywords: patch
Depends on: 28567
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-18 02:26 UTC by Guillaume Desmottes
Modified: 2019-12-03 20:06 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Guillaume Desmottes 2009-11-18 02:26:02 UTC
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
Comment 1 Stefan Hammer 2009-11-28 04:32:06 UTC
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..."
Comment 2 Will Thompson 2010-04-30 03:41:36 UTC
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.
Comment 3 Will Thompson 2010-05-02 07:04:11 UTC
Woo hoo!

Here's a branch that should fix this (and which tidies up connection-aliasing.c a bunch too).
Comment 4 Will Thompson 2010-05-02 07:31:16 UTC
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?
Comment 5 Simon McVittie 2010-05-11 06:17:51 UTC
(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.
Comment 6 Felix Kaser 2010-07-28 02:25:58 UTC
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
Comment 7 GitLab Migration User 2019-12-03 20:06:04 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.