GNOME Bugzilla – Bug 660535
Google contact groups/categories not showing in category list
Last modified: 2014-03-27 07:34:03 UTC
Running 3.2.0 in current Ubuntu 11.10 B2. Refresh is set to 1 minute for my Google contacts configured through Online Accounts. I noticed that only some of my Google groups are showing up in my Categories list. As best I can tell the groups that are configured in my local contacts and other legacy categories (from years of Evolution) are showing up in my list, and when they match my Google contact groups, all works as expected. Many of my Google groups are missing. The simple steps below reproduce the issue for me. a) In evolution create new contact "A" with new category "A" b) In evolution create new contact "AA" with new category "B" c) In Google contacts create new contact "AAA" with group "C" d) In Google contacts create new contact "AAAA" with group "D" In my browser, as I create the last contact I can already see all four new contacts and groups (A,B,C,D) in Google contacts. Switching windows to evolution shows all four contacts and properly configured Categories as well (including the additional "Personal" category for the two contacts created in Google contacts). e) Pull down the categories list and none of the new categories (A,B,C,D) are present f) evolution --force-shutdown g) Restart evo, still none of the new groups (A,B,C,D) showing as categories h) Add one of the missing groups (A,B,C,D) to a contact in a visible category, sill none of the new groups in the categories pulldown
As a final observation, I clean my data up in Google contacts (all four new contacts and the four new groups) and the contact modified in h) no longer shows the additional group I had added when viewed in Google contacts. In evolution, even after --force-shutdown, kill-factories, restart, the contact modified in h) shows the additional category, yet it does not show in the list, and does not appear in Google contacts.
Created attachment 271880 [details] [review] google: Add contact groups to Evolution’s category list This means they should automatically appear in Evolution’s category selector and editor. Previously, only new groups added manually by editing a Google contact in Evolution using the category editor were shown in the list.
This is a proof-of-concept patch which might fix the problem. I haven’t had a chance to compile it yet, but I think it’s along the right lines. I’ll try and find some time to test it, and poke someone to review it if it’s good.
Created attachment 272034 [details] [review] google: Add contact groups to Evolution’s category list This means they should automatically appear in Evolution’s category selector and editor. Previously, only new groups added manually by editing a Google contact in Evolution using the category editor were shown in the list.
The updated patch fixes this for me. Milan, how does it look?
Created attachment 272037 [details] [review] google: Add contact groups to Evolution’s category list This means they should automatically appear in Evolution’s category selector and editor. Previously, only new groups added manually by editing a Google contact in Evolution using the category editor were shown in the list.
(In reply to comment #5) > The updated patch fixes this for me. Milan, how does it look? Although thinking a little, it looks like ECategories is not thread safe, and thus potentially not safe to use from a backend thread. Milan, would you prefer it if I added locking to ECategories, or moved the new e_categories_*() calls to an idle callback in the main context?
I'd prefer to make ECategories thread-safe, even if that means deprecating some unsafe APIs and replacing them with "dup" or "ref" functions.
(In reply to comment #8) > I'd prefer to make ECategories thread-safe, even if that means deprecating some > unsafe APIs and replacing them with "dup" or "ref" functions. I vote for making ECategories thread-safe too. It'll be better for the future.
Review of attachment 272037 [details] [review]: Untested, but the patch looks fine. Unfortunately, as we reached hard-code freeze today, better to commit after it. It reminded me, with the thread-safety of e_categories_* functions, preferably do not touch the public API, due to stable branch constraints.
Created commit 4218c84 in eds master (3.13.1+) [1] Created commit bc34be1 in eds evolution-data-server-3-12 (3.12.1+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=4218c84
(In reply to comment #10) > Review of attachment 272037 [details] [review]: > > Untested, but the patch looks fine. Unfortunately, as we reached hard-code > freeze today, better to commit after it. It reminded me, with the thread-safety > of e_categories_* functions, preferably do not touch the public API, due to > stable branch constraints. Reopening because we haven't yet made ECategories thread safe. I'll try and find time to put together a patch for that soon.
(In reply to comment #12) > Reopening because we haven't yet made ECategories thread safe. Better to start a new bug report for it, to not mix different things, though related, into one bug report. I opened bug #727137 for it.