Bug 30631

Summary:	Need a flag to indicate that a ContactInfo field is overwritten by nickname
Product:	Telepathy	Reporter:	Jonathon Jongsma <jonathon>
Component:	tp-spec	Assignee:	Jonathon Jongsma <jonathon>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	Keywords:	patch
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:	review+
i915 platform:		i915 features:
Attachments:	ContactInfo: Add flag for fields that are overwritten by nickname ContactInfo: Add flag for fields that are overwritten by nickname ContactInfo: Add flag for fields that are overwritten by nickname

Description Jonathon Jongsma 2010-10-05 09:52:24 UTC

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

Comment 1 Jonathon Jongsma 2010-10-05 10:01:47 UTC

Created attachment 39182 [details] [review]
ContactInfo: Add flag for fields that are overwritten by nickname

It's likely that clients will want to expose the user's nickname and their
contact info in the same place for editing.  Howevever, many CMs map one of the
ContactInfo fields to the user's nickname, so editing these two fields
independantly at the same time results in surprising behavior.  Adding a flag to
the ContactInfo field will allow clients to hide these duplicate fields when
presenting them together.

Fixes: fd.o#30631

Comment 2 Jonathon Jongsma 2010-10-05 10:06:32 UTC

Comment on attachment 39182 [details] [review]
ContactInfo: Add flag for fields that are overwritten by nickname

uhh, I accidentally added this flag to Contact_Info_Flags instead of Contact_Info_Field_Flags, please ignore this patch.

Comment 3 Jonathon Jongsma 2010-10-05 10:08:23 UTC

Created attachment 39183 [details] [review]
ContactInfo: Add flag for fields that are overwritten by nickname

It's likely that clients will want to expose the user's nickname and their
contact info in the same place for editing.  Howevever, many CMs map one of the
ContactInfo fields to the user's nickname, so editing these two fields
independantly at the same time results in surprising behavior.  Adding a flag to
the ContactInfo field will allow clients to hide these duplicate fields when
presenting them together.

Fixes: fd.o#30631

Comment 4 Simon McVittie 2010-10-05 10:19:28 UTC

Review of attachment 39183 [details] [review]:

::: spec/Connection_Interface_Contact_Info.xml
@@ +473,3 @@
+
+      <tp:flag suffix="Overwritten_By_Nickname" value="2">
+        <tp:docstring>

Please set the XHTML xmlns on the <tp:docstring> and put the text in paragraphs, like so, to get better spacing in the HTML output:

<p>Indicates ... this field</p>

<tp:rationale>
  <p>If a client ... first.</p>
</tp:rationale>

You can abbreviate org.freedesktop.Telepathy to ofdT in namespace attributes.

The actual text of this change looks fine, but I'd prefer it if you also said something like:

    <p>If used, this flag typically appears on either the "nickname" or
      "fn" field.</p>

It also seems a good idea to recommend calling SetContactInfo *before* either calling SetAliases or setting the Nickname, if both were changed, so that it's harmless if the UI leaves the stale nickname in its "things to set" data structure. Hopefully we can rely on connection managers to handle overlapping edits correctly (Gabble does).

Comment 5 Jonathon Jongsma 2010-10-05 11:56:18 UTC

Created attachment 39187 [details] [review]
ContactInfo: Add flag for fields that are overwritten by nickname

It's likely that clients will want to expose the user's nickname and their
contact info in the same place for editing.  Howevever, many CMs map one of the
ContactInfo fields to the user's nickname, so editing these two fields
independantly at the same time results in surprising behavior.  Adding a flag to
the ContactInfo field will allow clients to hide these duplicate fields when
presenting them together.

Fixes: fd.o#30631

Comment 6 Simon McVittie 2010-11-09 06:47:15 UTC

Review of attachment 39187 [details] [review]:

(Sorry, I missed this for a while because the patch keyword was missing. Please add it when you want review on things.)

The patch looks fine, please merge.

::: spec/Connection_Interface_Contact_Info.xml
@@ +489,3 @@
+          </tp:rationale>
+          <p>In addition to hiding this field when editing ContactInfo together
+            with the user's nickname, it is recommended that clients call

Don't bother changing this now, but in future I'd prefer (the source code of) spec HTML to have a blank line between paragraphs, as seen here:

    <p>Something.</p>

    <p>Something else which you should imagine
      to be long enough to need wrapping.</p>

    <tp:rationale>
      <p>Because I said so.</p>
    </tp:rationale>

Comment 7 Jonathon Jongsma 2010-11-09 07:42:50 UTC

merged in a8f7f603bc1be3fd5ce66f01ec1ebf2b296f1a90

I'll remember to separate the paragraphs for next time.

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.