Bug 661033 - Add support for E_CONTACT_FILE_AS field
Add support for E_CONTACT_FILE_AS field
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Contacts
3.2.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
evolution[google]
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-10-05 23:16 UTC by Philip Withnall
Modified: 2011-11-14 23:01 UTC (History)
3 users (show)

See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add support for E_CONTACT_FILE_AS to EDS’ Google Contacts address book backend (3.29 KB, patch)
2011-10-27 13:06 UTC, Philip Withnall
reviewed Details | Diff | Review
Add support for E_CONTACT_FILE_AS to EDS’ Google Contacts address book backend (updated) (3.38 KB, patch)
2011-11-11 16:19 UTC, Philip Withnall
committed Details | Diff | Review

Description Philip Withnall 2011-10-05 23:16:29 UTC
It would be nice to support the E_CONTACT_FILE_AS field. IIRC, there isn't a native way to represent this in the Google Contacts API. However, EDS’ Google Contacts backend could easily just map it to a well-known named extended property.
Comment 1 Larry Reid 2011-10-27 00:22:12 UTC
This bug came out of my testing for bug https://bugzilla.gnome.org/show_bug.cgi?id=637144. I'd like to add a few more observations.

First, some background. I have a lot of contacts in Google Contacts who have two last names. Earlier versions of Evolution that used pre-version 3 of the Google Contacts API would pull the names into Evolution and sort them on the second last name, which isn't what I expected. Also, when trying to enter such names, Evolution wou

Evolution 2.32.2 uses version 3 of the Google Contacts API (so I'm told) and correctly stores and retrieves contacts with two last names in Google Contacts. However, it still sorts them based on the second last name. In addition, Evolution doesn't allow the user to change the "File as" field, which is what this bug is about.

Enough background. Here are some further observations: Google Contacts does have a "File as" field. I have confirmed through the Google Contacts user interface in gmail that my contacts don't have the "File as" field filled in. That leads me to believe that Evolution must generate its own "File as" field on the fly, and that it generates it the old way, i.e. by taking the last sequence of non-blank characters in the full name.

What I think Evolution should do in the absence of a "File as" field being provided by Google Contacts is to sort by last name, rather than the last sequence of non-blanks in the full name. If Evolution did that, then this bug would bother far fewer users, I think. It would still be nice to be able to use the "File as" field and store it in Google Contacts (it's there in the version 3 API), but the problem is really that, in the absence of "File as" info, Evolution is not sorting by the full contents of the last name field.

Sorry for the verbose description.
Comment 2 Philip Withnall 2011-10-27 07:57:54 UTC
Turns out that support for “file as” was added to the Google Contacts API (as you say) at the start of September 2011, which I completely missed: http://code.google.com/apis/contacts/changelog.html.

I've just added support for it to libgdata in what will become the 0.11.0 release at some point.
Comment 3 Philip Withnall 2011-10-27 13:06:15 UTC
Created attachment 200100 [details] [review]
Add support for E_CONTACT_FILE_AS to EDS’ Google Contacts address book backend

This adds support for E_CONTACT_FILE_AS to EDS’ Google Contacts address book backend. The support depends on libgdata ≥ 0.11.0 being available, but doesn't bump EDS’ minimum requirement.

(Note that libgdata 0.11.0 hasn't been released yet, but it will include the necessary API when it is.)
Comment 4 Milan Crha 2011-11-11 15:03:53 UTC
I do not see an issue with the patch, it pretty much straightforward, and I suppose you are waiting for 0.11.0 release of libgdata, because without that eds is not compilable:
   e...gle.c: In function 'e_book_backend_google_get_backend_property':
   e...gle.c:2339:56: error: missing binary operator before token "("
   e...gle.c: In function '_gdata_entry_update_from_e_contact':
   e...gle.c:2659:56: error: missing binary operator before token "("
   e...gle.c:2689:56: error: missing binary operator before token "("
   e...gle.c: In function '_e_contact_new_from_gdata_entry':
   e...gle.c:3018:56: error: missing binary operator before token "("
   e...gle.c:3051:56: error: missing binary operator before token "("
Thus when 0.11.0 is out, and when it's available, bump the version or check in configure.ac and commit it.
Comment 5 Philip Withnall 2011-11-11 16:19:54 UTC
Created attachment 201244 [details] [review]
Add support for E_CONTACT_FILE_AS to EDS’ Google Contacts address book backend (updated)

The patch was supposed to compile regardless of whether libgdata 0.11.0 is available. I didn't test it without libgdata 0.11.0 though, and just assumed cpp would short-circuit the #ifs if GDATA_CHECK_VERSION wasn't defined. Whoops.

Updated patch which compiles with and without libgdata 0.11.0 (tested this time). The only thing I've changed is the #ifs.
Comment 6 Milan Crha 2011-11-14 11:00:14 UTC
Looks good (tested without libgdata 0.11. Feel free to commit to master.
Comment 7 Philip Withnall 2011-11-14 23:01:05 UTC
Pushed to master. Thanks!

commit 31e12b510a566fc4467fc0f46ea32fc5c7d93f37
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Thu Oct 27 14:02:20 2011 +0100

    Bug 661033 — Add support for E_CONTACT_FILE_AS field
    
    Add support for E_CONTACT_FILE_AS to the Google Contacts address book backend
    if libgdata ≥ 0.11.0 is available. This doesn't bump EDS’ required libgdata
    version.
    
    Closes: bgo#661033

 .../backends/google/e-book-backend-google.c        |   43 +++++++++++++++++++-
 1 files changed, 42 insertions(+), 1 deletions(-)

Note You need to log in before you can comment on or make changes to this bug.