Background:
We are using AD to auto users. Everything works very well. Thanks for a great product. We do, however, have one issue.
Issue:
Users are unable to dynamically create a group chat. When trying to join (create) a non-existing room, the room is created and viewable via the admin interface. No joins work with the response ’ 404: Recipient Unavailable’. The room is in the state “Locked” and can be discovered, however, it can not be joined as no-one owns it. If we go into the chat permissions and add an owner manually, the room unlocks and then is able to be configured (via a xmpp client.) After adding an owner, everything works as expected. Please advise.
Note:
Having to file a bug via the forum was a pain. Specifically because my user from the bug tracker is not valid on the forums.
We have just updated to 3.5.1 and still see this issue.
It also seems that the manually added owner permissions don’t persist after a reboot.
Hey Jonathan,
Rooms need to be configured after they have been created. Otherwise they will remain locked thus joins will be rejected. Clients may be fine with using the server defaults for rooms but still they need to tell the server that default values are fine for the room. BTW, those rooms are called instant rooms. Make sure that you client is configuring the room after it was created.
Regards,
– Gato
Is there any way to set a default owner? How about the default owner be the user that started the instant rooms? Pidgin seems to offer configuring of the room, after an owner is set.
Hey Jonathan,
Is there any way to set a default owner?
Why is it that you want to be the owner of the room? Fastpath will create a new room for each chat support session. Once the room has been created and configured (by FP) invitations are sent to the agent and the end user.
– Gato
Hi -
Upon further investigation, it looks like a query to our mucRoom.roomPassword column was off. For whatever reason, there was a ‘password’ column, but not a roomPassword column.
I took the Openfire source, examined the .sql schema, and found that this was the only anomoly in our database. I altered the table like so:
ALTER TABLE mucRoom CHANGE password roomPassword VARCHAR(50) DEFAULT NULL;
We can now create rooms with defaults, the same as we could before.