GNOME Bugzilla – Bug 630358
Google contacts doesn't sync birthday and URL
Last modified: 2011-03-09 12:09:11 UTC
Evolution doesn't show birthday for google contacts
Thanks for a bug report. Evolution is using libgdata and I didn't find API for this field, thus I'm moving this to libgdata. There is also a URL field in both Google and Evolution, which is not synced.
libgdata master has gdata_contacts_contact_[get|set]_birthday(), which will be available in 0.7.0. http://git.gnome.org/browse/libgdata/tree/gdata/services/contacts/gdata-contacts-contact.h#n170 Changing the product so it's an e-d-s bug to make use of the functions once libgdata 0.7.0 is released and e-d-s depends on it.
OK, thanks. What about that URL field?
Should be covered by the website functions in the same class: http://git.gnome.org/browse/libgdata/tree/gdata/services/contacts/gdata-contacts-contact.h#n239
Created attachment 172244 [details] [review] eds patch for evolution-data-server; Though this is still waiting for libgdata 0.7, then there weren't as that many API changes, thus I got eds ready for it, so when the eds will be compiled against 0.7 or higher libgdata, then fields like birthday, home page url and blog url will be available in UI and will be synced forth and back from the Google server. Philip, I noticed they support also anniversary dates, it would be nice to have API for it in 0.7 too. Also, I'm ignoring dates without year, I've not much idea what to do with such dates, because evolution depends on the birthday year.
Created commit b1c896e in eds master (2.91.1+)
(In reply to comment #5) > Created an attachment (id=172244) [details] [review] > eds patch > > for evolution-data-server; > > Though this is still waiting for libgdata 0.7, then there weren't as that many > API changes, thus I got eds ready for it, so when the eds will be compiled > against 0.7 or higher libgdata, then fields like birthday, home page url and > blog url will be available in UI and will be synced forth and back from the > Google server. Thanks for doing this! > Philip, I noticed they support also anniversary dates, it would be nice to have > API for it in 0.7 too. Also, I'm ignoring dates without year, I've not much > idea what to do with such dates, because evolution depends on the birthday > year. Anniversaries are supported as a type of “event”: http://code.google.com/apis/contacts/docs/3.0/reference.html#gcEvent. You can access them using the event API on GDataContactsContact: http://git.gnome.org/browse/libgdata/tree/gdata/services/contacts/gdata-contacts-contact.h#n244. Couldn't you just use the current year if the year is missing? That would prevent data loss in the case that someone's just stored the day and month (which is all one really needs to store in most cases).
(In reply to comment #7) > Anniversaries are supported as a type of “event”: Aha, I wouldn't expect it there. > Couldn't you just use the current year if the year is missing? Yes, I thought of that, but it'll break years-old computation and most notably if you edit the contact in evolution then it'll write there its year. Though maybe it's better than data-loss.
Created attachment 172335 [details] [review] eds patch ][ for evolution-data-server; And anniversary + birth day without year (though this is untested).
Created commit bad12c4 in eds master (2.91.1+)
(In reply to comment #9) > Created an attachment (id=172335) [details] [review] > eds patch ][ > > for evolution-data-server; > > And anniversary + birth day without year (though this is untested). Instead of calling gdata_contacts_contact_remove_all_events(), you should probably loop through and only delete the anniversary events, rather than all events. Data loss (of non-anniversary events) could occur otherwise. This is probably true of websites/blogs too.
Created attachment 172364 [details] [review] eds patch ]I[ for evolution-data-server; Aha, I thought it's creating a new 'event' from scratch, and those 'remove_all' are there just to be sure, but I see that events are recreated from the cache and updated accordingly to user changes. The only issue is that the order changes, and updated anniversary and/or homepage/blog websites are at the bottom. Not much I can do with it, right? Unless we've some remove_reltype for both events and websites and 'add' taking care of duplicates, because otherwise it's too complicated code for this. (And I know, that's also hard to find duplicates in events.) Anyway... Created commit 003ebce in eds master (2.91.1+)
(In reply to comment #12) > The only issue is that the order changes, and updated anniversary and/or > homepage/blog websites are at the bottom. Not much I can do with it, right? That shouldn't be an issue. > Unless we've some remove_reltype for both events and websites and 'add' taking > care of duplicates, because otherwise it's too complicated code for this. (And > I know, that's also hard to find duplicates in events.) Anyway... The problem with adding API like *_remove_reltype() to libgdata is that if I add it for events, it also has to be added for websites, calendars, hobbies, languages, external IDs, etc. That rapidly turns into an awful lot of very repetitive API. I'm considering moving to some kind of API when GDataContactsContact would export a container object for each of {websites, calendars, hobbies, languages, …}, and the container would provide a uniform interface for interacting with the collection of items. e.g. GDataCollection *collection = gdata_contacts_contact_get_events (); Event *some_event = gdata_collection_get (collection, "some-id"); gdata_collection_remove_by_relation_type (collection, ANNIVERSARY); gdata_collection_add (collection, some_other_event); How does that sound? I'm not sure it would make 0.7 though, as I don't have much free time at the moment.
(In reply to comment #13) > The problem with adding API like *_remove_reltype() to libgdata is that if I > add it for events, it also has to be added for websites, calendars, hobbies, > languages, external IDs, etc. That rapidly turns into an awful lot of very > repetitive API. > ... Yeah, I know, it's all about very similar API for different properties. And to be honest I do not care much at the moment, I have it done for google contacts in evolution already, so it was just an idea.
*** Bug 631362 has been marked as a duplicate of this bug. ***
*** Bug 631663 has been marked as a duplicate of this bug. ***
Birthday from evolution are not visible in gmail-contacts after transfer by sync-ui (syncml). Evolution-Version: 2.30.3
(In reply to comment #17) > Birthday from evolution are not visible in gmail-contacts after transfer by > sync-ui (syncml). > Evolution-Version: 2.30.3 It doesn't surprise that much if you read comment #6, comment #10, comment #12 carefully...
Oooops =) I did not checked the version because the comment was older so i thought it must be still in my evolution... Sorry =)
(In reply to comment #19) > Oooops =) I did not checked the version because the comment was older so i > thought it must be still in my evolution... Sorry =) No problem, this bug history is quite confusing, with its three patches instead of just one :)