Bug 29728

ContactManager::addGroup is described as "Attempt to add an user-defined contact list group". Therefore, (and judging from the naming), one would expect that after the returned PendingOperation has finished successfully, the group would have actually been added (I know, right?), and would be usable for eg. adding contacts to it.

In reality however, the PendingOperation finishes as soon as the underlying EnsureChannel D-Bus call to the CM has returned. While this is, indeed, when the group is actually added at the CM level, at this point the ContactManager internals still haven't picked up the new group, and, for example, trying to add a contact to the seemingly newly-added group fails! A work-around is to wait for the groupAdded signal for the group in question - but this is really error-prone, as the signal may well have been emitted already (and will be, if we fix this bug properly)!

The fix would be to make a private PendingOperation subclass, which would first make the EnsureChannel call, and if that's successful, and the new group hasn't been picked up yet, wait for the new group to be picked up (by the groupAdded() signal) before finishing. Then, the operation being finished() would truly mean that the group is now usable by the usual methods manipulating it.

Similarly, the removeGroup PendingOperation returns as soon as the Channel's Close method has returned (and the group has been removed from the server). However, contacts can still seemingly be added to the group etc. until the channel being invalidated is picked up by the ContactManager internals, and groupRemoved() is emitted (probably in the next few mainloop iterations)! This is less of a problem though, as you generally shouldn't need to worry about a removed group anymore - it's still confusing however, as the PendingOperation to eg. add a contact to a group in this state will probably fail with "The method AddMembers on bahbah interface doesn't exist" (because the Channel doesn't exist anymore) instead of the intended "The group doesn't exist".

The fix for this, then, is obviously waiting for groupRemoved in the removeGroup PendingOperation if the group still exists in the ContactManager internals after the Channel has been closed.