After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 679743 - TpfPersona created using tpf_persona_dup_for_contact() don't have any group
TpfPersona created using tpf_persona_dup_for_contact() don't have any group
Status: RESOLVED WONTFIX
Product: folks
Classification: Platform
Component: Telepathy backend
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2012-07-11 11:13 UTC by Guillaume Desmottes
Modified: 2012-07-19 09:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Guillaume Desmottes 2012-07-11 11:13:48 UTC
- Empathy: join a XMPP muc containing contacts you don't have in your roster
- Right click on one of those and choose 'Add Contact...'
- The group widget in the add dialog doesn't contain any of your XMPP group.

Empathy use the group list returned by folks_group_details_get_groups() which works well for roster contacts (returned by the aggregator) but not for those creating manually using tpf_persona_dup_for_contact().
Comment 1 Philip Withnall 2012-07-11 20:30:02 UTC
(In reply to comment #0)
> Empathy use the group list returned by folks_group_details_get_groups() which
> works well for roster contacts (returned by the aggregator) but not for those
> creating manually using tpf_persona_dup_for_contact().

I can’t test this because I don’t know of any XMPP MUCs (sorry).

However, folks’ code here is quite simple. Basically, it just listens to TpContact::contact-groups-changed and maintains a set of group names accordingly. The set is initialised from TpContact.get_contact_groups() when the Tpf.Persona is created. There should be no difference in how folks treats personas created using Tpf.Persona.dup_for_contact() compared to the ones which come from the normal roster.

Is it possible that TpContact.get_contact_groups() isn’t returning what you expect?
Comment 2 Guillaume Desmottes 2012-07-12 07:23:27 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Empathy use the group list returned by folks_group_details_get_groups() which
> > works well for roster contacts (returned by the aggregator) but not for those
> > creating manually using tpf_persona_dup_for_contact().
> 
> I can’t test this because I don’t know of any XMPP MUCs (sorry).

I just joined test@conference.jabber.belnet.be if you want to test.
 
> However, folks’ code here is quite simple. Basically, it just listens to
> TpContact::contact-groups-changed and maintains a set of group names
> accordingly. The set is initialised from TpContact.get_contact_groups() when
> the Tpf.Persona is created. There should be no difference in how folks treats
> personas created using Tpf.Persona.dup_for_contact() compared to the ones which
> come from the normal roster.
> 
> Is it possible that TpContact.get_contact_groups() isn’t returning what you
> expect?

TpContact.get_contact_groups() will return an empty set as the contact is not in any group.

But according to http://telepathy.freedesktop.org/doc/folks/c/FolksGroupDetails.html#FolksGroupDetails--groups the "groups" property is a mapping group-name -> boolean. So it should contain all the groups known on this store with FALSE as value.

That's what happen when we receive a subscription request. The hash contains all the groups with FALSE so the widget can present them all to user.
Comment 3 Philip Withnall 2012-07-19 04:09:09 UTC
(In reply to comment #2)
> But according to
> http://telepathy.freedesktop.org/doc/folks/c/FolksGroupDetails.html#FolksGroupDetails--groups
> the "groups" property is a mapping group-name -> boolean. So it should contain
> all the groups known on this store with FALSE as value.

Looks like that documentation’s out of date, from when we used a GHashTable mapping from group ID to a boolean. Since 0.5.x, folks has used a GeeSet for GroupDetails.groups. I’ve just updated the documentation.

I’m fairly sure the documentation was never meant to mean that all groups would be present in the hash table (and set to TRUE/FALSE as appropriate) — I think the hash table was being used purely as a set.

In any case, the behaviour you’re looking for can’t be supported by GeeSet anyway.
Comment 4 Guillaume Desmottes 2012-07-19 09:09:25 UTC
Ok my bad, I failed at reading source code, you're right...