[Telepathy] [Bug 17769] New: MUC channels are created with Can_Add which is immediately removed

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=17769

           Summary: MUC channels are created with Can_Add which is
                    immediately removed
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: low
         Component: telepathy-gabble
        AssignedTo: telepathy at lists.freedesktop.org
        ReportedBy: will.thompson at collabora.co.uk


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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.