Project

General

Profile

muc#roomconfig_roomadmins broken ?

kellogs .
Added 7 months ago

Hello,

downloaded latest nightly build of tigase as of today from http://build.xmpp-test.net/nightlies/dists/latest/tigase-server-dist-max.tar.gz

I have tried setting up a list of admins for an existing MUC room like so:

<iq id='create2'
    to='maglavais@muc.domain.com'
    type='set'>
  <query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='submit'>
      <field var='muc#roomconfig_roomadmins'>
        <value>kellogs2@domain.com</value>
      </field>
    </x>
  </query>
</iq>

<iq from="maglavais@muc.domain.com" type="result" to="admin@domain.com/kellogs-PC" id="create2"/>

in the logs I can see:

017-06-19 12:44:04.225 [in_3-muc]         PresenceFiltered.onSetAffiliation()     FINEST:   Modifying affiliation of: kellogs2@domain.com on occupantsPresenceFiltered: [[]]
2017-06-19 12:44:04.225 [in_3-muc]         Room.getAffiliation()                   FINEST:   Getting affiliations for: kellogs2@domain.com from set: {kellogs2@domain.com=admin, admin@domain.co=owner}

However upon joining the room with the newly setup admin user:

<presence from="maglavais@domain.com/kellogs2" to="kellogs2@domain.com/kellogs-PC">
<priority>5</priority>
<c xmlns="http://jabber.org/protocol/caps" node="http://psi-im.org/caps" ver="caps-b75d8d2b25" ext="cs ep-notify-2 html"/>

<x xmlns="http://jabber.org/protocol/muc#user">
<item affiliation="none" nick="kellogs2" role="participant"/>
<status code="110"/>
</x>
</presence>

Some more info from the db:

mysql> select * from tig_muc_room_affiliations where room_id=378;
+---------+-----------------------------+------------------------------------------+-------------+
| room_id | jid                         | jid_sha1                                 | affiliation |
+---------+-----------------------------+------------------------------------------+-------------+
|     378 | admin@domain.com            | 4386256acf3c850c061c9c9b2b6910c06a76af62 | owner       |
+---------+-----------------------------+------------------------------------------+-------------+

| 378 | maglavais@domain.com | f11c9a4ba7d0cdc36d84836e657c97ec789961ff | NULL | truetruefalsefalse0semianonymoustrue0html50PREFERE_PRIORITY0 | admin@domain.com | 2017-06-19 12:04:51.169000 | NULL | NULL | NULL |

I have also tried setting the kellogs2@domain.com jid as an owner with a similar outcome. Am I doing it wrong ?


Replies (2)

Added by Bartosz Malkowski 7 months ago

Field muc#roomconfig_roomadmins is not stored in database because it is processed in different way (there is separate affiliation storage).

I added tests to cover this problem but tests works. Would you like to check test scenario here

The only thing I added is field muc#roomconfig_roomadmins in room config result.

Added by kellogs . 7 months ago

Thank you Bartosz, I have spotted the difference between what I was sending and what the linked test scenario sends, namely:

      <field var="FORM_TYPE">

        <value>http://jabber.org/protocol/muc#roomconfig</value>

      </field>

I have included that one and it seems all fine now.

mysql> select * from tig_muc_room_affiliations where room_id=378;
+---------+----------------------------------------------+------------------------------------------+-------------+
| room_id | jid                                          | jid_sha1                                 | affiliation |
+---------+----------------------------------------------+------------------------------------------+-------------+
|     378 | kellogs3@domain.com                          | 1903fba1055b994eb27bf8aa7462dd053553af02 | outcast     |
|     378 | admin@domain.com                             | 4386256acf3c850c061c9c9b2b6910c06a76af62 | owner       |
|     378 | kellogs2@domain.com                          | f8b61a58a40dcb8311a5d011f3bf10004d02cef8 | admin       |
+---------+----------------------------------------------+------------------------------------------+-------------+

Perhaps it would be a good idea to send back to client an stanza instead of the stanza in such scenarios.

    (1-2/2)