Commit 4cf5ab69 authored by Patrick Ohly's avatar Patrick Ohly

eds: handle removal of store without removal of personas

The assumption in the IndividualAggregator that all backends remove
their personas before removing a store did not hold for the EDS
backend when stores were removed via set_persona_stores() or

Fixing that in EDS is tricky, so better make the IndividualAggregator
more resilient and remove any remaining personas when the store gets

parent 7c0f8f94
......@@ -20,6 +20,7 @@ Bugs fixed:
• Bug 688834 — getting properties creates data structures over and over again
• Bug 688923 — remove URLs (blog, free/busy, video, home page)
• Bug 689146 — disabling EDS address books does not remove personas
API changes:
• Add Backend.enable_persona_store and disable_persona_store.
......@@ -904,9 +904,24 @@ public class Folks.IndividualAggregator : Object
this._notify_if_is_quiescent ();
/* no need to remove this store's personas from all the individuals, since
* they'll do that themselves (and emit their own 'removed' signal if
* necessary) */
/* Not all stores emit a 'removed' signal under all circumstances.
* The EDS backend doesn't do it when set_persona_stores() or disable_store()
* are used to disable a store.
* Therefore remove this store's personas from all the individuals. Should
* not have any effect if a store already triggered the 'removed' signals,
* because then we won't have anything here.
* See
var removed_personas = new HashSet<Persona> ();
var iter = store.personas.map_iterator ();
while ( () == true)
removed_personas.add (iter.get_value ());
this._personas_changed_cb (store, new HashSet<Persona> (), removed_personas,
null, null, GroupDetails.ChangeReason.NONE);
if (this._primary_store == store)
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment