Adium

Ticket #10106 (closed defect: fixed)

Opened 4 months ago

Last modified 3 months ago

AddressBook information shown as unique identifiers

Reported by: gshapiro Assigned to:
Priority: normal Milestone: SVN issues
Component: Contact Inspector Version: 1.3b3
Severity: normal Keywords:
Cc: Patch: Accepted
Pending: 0

Description

Get Info on a contact with an AddressBook entry and you'll see fields like: 

url         8931AB32-E4FC-11D9-8EBF-000393B9947A
homephone   ADF5F16B-3EFD-11D8-93F5-000393A8C5E8
homeemail   ADF6227A-3EFD-11D8-93F5-000393A8C5E8

Some contacts also show "workim", "workaddress", "homeim", "homeaddress", and various other phone numbers in the same way. Those fields aren't useful so should not be included in that form since they are already included in readable form as "homepage", "phone (home)", and "email (home)". Note that the "*im" and "*address" fields are not shown in a human readable form.

This problem is also present in 1.3b3.

Also, while on the subject, AddressBook cards imported from a directory also have this field shown: 

remotelocation (ldap)     ldap://ldap.smi.sendmail.com:389/ou=People,dc=sendmail,dc=com??sub?(&(givenname=Gregory)(sn=Shapiro))

This probably shouldn't be shown either. However, if you do keep it, it should be fixed as Adium makes it into a link but only linkifies "mi.sendmail.com:389/ou=People,dc=sendmail,dc=com??sub?(&(givenname=Gregory) (sn=Shapiro))" as a link pointing to "http://mi.sendmail.com:389/ou=People,dc=sendmail,dc=com??sub?(&(givenname=Gregory)(sn=Shapiro))" (see attached image).

Attachments

Picture 2.jpg (17.7 kB) - added by gshapiro on 06/14/2008 05:00:13 PM.
Example of bad linkification for AddressBook info
patch.txt (2.0 kB) - added by gshapiro on 06/15/2008 04:27:18 PM.
Patch to fix the problem (now with field sorting)

Change History

06/14/2008 05:00:13 PM changed by gshapiro

  • attachment Picture 2.jpg added.

Example of bad linkification for AddressBook info

(follow-up: ↓ 2 ) 06/14/2008 10:51:09 PM changed by jas8522

  • pending set to 1.
  • milestone set to Needs feedback from users.

I can't reproduce this with 1.3b3 ... checked it out with at least three different contacts who show other address book information just fine...

Please try b3 and get back to us.

(in reply to: ↑ 1 ) 06/14/2008 11:27:11 PM changed by gshapiro

  • pending deleted.

Replying to jas8522:

I can't reproduce this with 1.3b3 ... checked it out with at least three different contacts who show other address book information just fine... Please try b3 and get back to us.

The examples I gave are from beta 3 (as mentioned in the original report). I couldn't set that version as Trac didn't have it at the time I reported the problem.

06/14/2008 11:30:29 PM changed by jas8522

  • version changed from 1.3b2 to 1.3b3.

Ahh, I missed that little line ;)

If you open address book, these entries appear? Are you sure that's not because of some 3rd party app entering them? I don't have any entries like that showing up either in Address Book or in Adium contact profiles.

06/14/2008 11:38:45 PM changed by gshapiro

The AddressBook entries look fine.

06/15/2008 02:11:39 AM changed by evands

  • milestone changed from Needs feedback from users to Adium X 1.3.

06/15/2008 02:40:24 AM changed by gshapiro

This is just a guess at this point, but is it possible that these extra fields are actually the labels, such as kABEmailWorkLabel, kABEmailHomeLabel, etc. that are coming from the multivalue properties such as kABEmailProperty?

06/15/2008 01:29:40 PM changed by gshapiro

I am trying to debug this and so far have found that the property loop in addAddressBookInfoToProfileArray is picking up both a workEmail property (with an NSString value of the GUID) and a kABEmailProperty with the proper data. This could be caused by a couple of different possibilities. Perhaps since my AddressBook data has been around forever, an older version of AddressBook used these fields and later converted to the multi-value fields. Or perhaps another application has put these fields in there (I did note a lot of odd field names when iterating through the properties object).

Perhaps the best solution for this problem is to have Adium specifically request the properties it wants to show instead of trying to figure out what it doesn't want to show.

(follow-up: ↓ 9 ) 06/15/2008 01:30:55 PM changed by zacw

The problem with that is, it'd never show custom fields (which are still important to be shown).

(in reply to: ↑ 8 ; follow-up: ↓ 10 ) 06/15/2008 01:38:04 PM changed by gshapiro

Replying to zacw:

The problem with that is, it'd never show custom fields (which are still important to be shown).

I'll see if I can find a way to tell the difference between an AddressBook user created custom field and a custom field added by a different application that shouldn't be shown. Basically, if AddressBook doesn't show the field, neither should Adium.

(in reply to: ↑ 9 ) 06/15/2008 01:40:58 PM changed by gshapiro

Ha, nice trick. AddressBook doesn't let you create custom fields. So which custom fields are you talking about?

(follow-up: ↓ 12 ) 06/15/2008 03:08:09 PM changed by gshapiro

The attached patch fixes the problem by changing propertiesToExclude to propertiesToInclude. Since there can't be custom fields in AddressBook, only custom labels, this patch gets exactly what you want -- the AddressBook displayable fields. Custom labels still work. This also fixes the "RemoteLocation" problem.

A further enhancement might be to control the order of the information shown instead of using the random order returned by the enumerator.

06/15/2008 04:27:18 PM changed by gshapiro

  • attachment patch.txt added.

Patch to fix the problem (now with field sorting)

(in reply to: ↑ 11 ) 06/15/2008 04:29:53 PM changed by gshapiro

Replying to gshapiro:

A further enhancement might be to control the order of the information shown instead of using the random order returned by the enumerator.

I just replaced the patch with a new one that does control the order of information shown. It simply changed the logic to enumerate through propertiesToInclude (now an NSArray since NSSet's don't preserve order) instead of the properties of the person.

This is better since you can now put title, department, and organization together (for example).

06/15/2008 05:16:26 PM changed by jas8522

  • patch_status changed from None to Needs Dev Review.

06/15/2008 06:59:09 PM changed by evands

  • status changed from new to closed.
  • resolution set to fixed.

(In [23998]) Patch from Gregory Shapiro to improve display of Address Book info in the contact inspector. We now declare the info we want and add it in a sane order rather than getting spurious information and adding it in random order. Thanks! :) Fixes #10106

06/15/2008 07:00:59 PM changed by Robby

  • milestone changed from Adium X 1.3 to SVN issues.

07/12/2008 07:13:20 AM changed by Robby

  • patch_status changed from Needs Dev Review to Accepted.