| Summary: |
MUC channels are created with Can_Add which is immediately removed |
| Product: |
Telepathy
|
Reporter: |
Will Thompson <will> |
| Component: |
gabble | Assignee: |
Telepathy bugs list <telepathy-bugs> |
| Status: |
RESOLVED
MOVED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
minor
|
|
|
| Priority: |
low
|
|
|
| Version: |
unspecified | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
| Attachments: |
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.
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.