[Bug 30631] New: Need a flag to indicate that a ContactInfo field is overwritten by nickname
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Oct 5 18:52:25 CEST 2010
Summary: Need a flag to indicate that a ContactInfo field is
overwritten by nickname
AssignedTo: telepathy-bugs at lists.freedesktop.org
ReportedBy: jonathon at quotidian.org
QAContact: telepathy-bugs at lists.freedesktop.org
Empathy allows the user to edit the Alias and the ContactInfo in the same
dialog. The problem is that in some CMs, one of the ContactInfo fields is
actually mapped to the alias. So even though both of these fields can be set
independantly, they result in the same property being set in the CM. This can
result in surprising behavior.
As discussed on IRC, we propose adding a ContactInfo flag that indicates that a
particular field is overwritten when the user's nickname is set.
I think we need to clarify what to do when the protocol uses fn as the alias
<smcv> alsuren_: by which you mean "thing you set on yourself" not "thing you
set on other people" I hope?
alsuren_: Gabble has a similar but even nastier situation
<smcv> alsuren_: older servers/clients use nickname if set, or fn
our solution in Gabble was to just expose both nickname and fn in ContactInfo,
and also whichever is set as the alias
if you delete your fn *and* your nickname, you lose
<jonner> smcv, my specific issue is e.g. in empathy's Edit->personal
there's an entry for both fullname and alias
so if they both map to the same property, but the user sees them as two
separate things, that's confusing.
because they could set them to different values and they'd stomp on eachother.
<smcv> jonner: hmm, I see what you mean
<smcv> although I notice Empathy accidentally mitigates this by not showing
nickname as editable...
<jonner> hm, I don't have a nickname on my accounts, I guess.
<smcv> maybe we need a ContactInfo flag for "this will be mangled if you change
or maybe we should always exclude the "best" alias field, which would be
NICKNAME on XMPP
<jonner> smcv, yeah, my current solution was just going to be removing the
alias-like field from ContactInfo
but that's not entirely satisfactory
<alsuren_> jonner: just been talking to smcv in person. I think we have a
proposed change to the spec
<jonner> nice. got a summary?
<alsuren_> jonner: he'll burble at you in a minute, but adding a flag to
<smcv> jonner: ok so my idea is
jonner: define a flag whose semantics are "when you set your own nickname,
this field will be changed as a side-effect"
<alsuren_> I would guess also recommending that a UI which edits both should
call SetContactInfo before SetAlias
<smcv> then UIs like Empathy, which put alias and contact info in the same
place, would hide that field
but a UI that separated those functions would show it
<jonner> right, hiding the field seems better than ordering the set.
<alsuren_> or that :P
<smcv> something like Contact_Info_Field_Flag_Overwritten_By_Nickname which
would typically appear on either FN or NICKNAME, or conceivably N if the
protocol is extremely strange
<jonner> how about CONTACT_INFO_IS_ALIAS_FOR_ALIAS ? :P
<smcv> I don't want to call this "Alias"
in the Names world, it's your nickname
hyperlink it to both Account.Nickname and SetAliases
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs