Bug 17769 - MUC channels are created with Can_Add which is immediately removed
Summary: MUC channels are created with Can_Add which is immediately removed
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: low minor
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-25 06:59 UTC by Will Thompson
Modified: 2008-09-25 07:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
a patch in the vague direction of what should change (1.41 KB, patch)
2008-09-25 07:01 UTC, Will Thompson
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Will Thompson 2008-09-25 06:59:27 UTC
New MUC channels' group flags are initialized as follows:

  /* set initial group flags */
  tp_group_mixin_change_flags (obj,
      TP_CHANNEL_GROUP_FLAG_PROPERTIES |
      TP_CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES |
      TP_CHANNEL_GROUP_FLAG_HANDLE_OWNERS_NOT_AVAILABLE |
      TP_CHANNEL_GROUP_FLAG_CAN_ADD,
      0);

Then, when requesting a MUC, we have:

      /* deny adding */
      tp_group_mixin_change_flags (obj, 0, TP_CHANNEL_GROUP_FLAG_CAN_ADD);

I believe that when you are invited to a MUC, you should be in local pending and thus CanAdd should not be set until you move to members, but this does not seem to be the case.  Regardless, it is misleading to initially set CanAdd and immediately remove it on requested channels.

tests/twisted/muc/test-muc.py is buggy in a related way: it expects a GroupFlagsChanged signal with removed=0.  It just so happens that it catches the first signal and not the second, so the assertion succeeds, but the assertion is incorrect: until the conference server has allowed you into the MUC, you should not be able to add new members.
Comment 1 Will Thompson 2008-09-25 07:01:13 UTC
Created attachment 19196 [details] [review]
a patch in the vague direction of what should change


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.