[Bug 30631] New: Need a flag to indicate that a ContactInfo field is overwritten by nickname

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30631

           Summary: Need a flag to indicate that a ContactInfo field is
                    overwritten by nickname
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-spec
        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.

irc transcript:
<alsuren_> in
http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Info.html#Contact_Info_Field
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
Information dialog
 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
your alias"
 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
Contact_Info_Field_Flags
<jonner> ok
<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.
 yeah
<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.