Prevent users from leaving a default join room

Hi, is there a setting to prevent users from leaving a room? We are using 4.6 with AD and have created a conference room for all users to auto join; but I cant find any setting to prevent the users from leaving this particular group. Thanks in advance.

Short of creating a custom client, I do not think that’s possible.

Ouch @guus – thanks for the info. Maybe a feature request for future?
I thought there is a property smth like room.DisableUsersLeaveMUC = 1 :slight_smile:

What would such a feature do, specifically? Instruct clients to not allow an interface element that is displaying a chat room to be closed?

Hi @guus yes, if the interface element is of MUCofChoice then disable any close button ?

I’m not sure I’m seeing the added benefit here, from a functional perspective. If people mistakenly close a chat, they can re-open it through bookmarks. If people choose to not want to pay attention to a chat, they can do that too. What problem is it that you’re trying to solve?

Thanks.
I am thinking that the room will be a public site-wide chat room where we can run chatbots or automation to send updates or messages to rooms rather than using broadcast. This include image etc. Additionally, we have an intranet and we can pipe new updates from web to this chat group etc.

Users can still create and join other group chats we can use chatbot to respond to #faqs request; and other users can benefots from the Q&A

This is something we saw in converse; ie users cant leave room if they are owners; so i guess we can make all users owners of this particular room?

Thanks, I hope the above makes sense.

rgds

I can see how having a shared room can be beneficial - but why the insistence on users not being able to leave the room?

Specific for our case, this is a request from my boss and her boss for 50 employees that are requesting a chat group for everyone so it is more interactive (rather that using the forum in the intranet) lol…

I think an option for room admin to make room not leave-able would be a good option for situation like this.

Hello!
I, like you already asked this, but we will run into XEP-0045.
I don’t think someone will change the behavior of Spark or Openfire with MUC …

I didnt know this is against MUC policies if that’s what the XEP-0045 is about. Forced group MUC seems more advanced tho’.

I understand you, but developers cannot leave XEP.
I myself am very disappointed that the MUC turns out to be useless. = (

I already wrote in the topic how you can make people start using MUC, but there are no active Spark developers for implementation.

Given that many million people use MUC daily, I wouldn’t say it is useless.

Also, there is room to extend MUC specifications with custom functionality - but in the grander scheme of this, that will introduce behavioral differences depending on what client you use. That is often undesirable.

Hi Guus, this can be one feature to extend the fuctionality in MUC and Sparks. Just hoping this will be considered in future. Thanks again.

I think only for donations they can do it. Or find a developer who can do it in Spark.
https://www.igniterealtime.org/support/service_providers.jsp

This is an Open Source product, here the developers decide for themselves what needs to be implemented. :shushing_face:

Not surprising :slight_smile: “Hey, users don’t want to engage in chat. Then force them!”

The problem with this is for a fringe edge case you have to create a weird Frankenstein function. How this will work? X button not working in this case or X button removed completely from a chat window? This will be confusing and annoying to users and you will get lots of calls asking why X is not working :slight_smile:

It’s not like we are only wanting features that we like personally (although this is somewhat true, as we have invested many years into these projects and care about them), but we try to gauge what is feasible and beneficial and what is a rare case and braking the design and philosophy.

Just a thought.

I think the approach is to have a admin-created channel that is selected as an option by the admin when creating the MUC to be a shoutbox or corporative announcement. This is a special channel and not about forcing users to chat. It is also special because in a company setting, this can be used for employee-wide automation etc etc as mentioned above. Users creating their own MUC wont have the option to set a special channel to avoid user confusion as you mentioned.

How it works? Disable the X when on this chat. The window title can even be marked “Shoutbox” to prevent users from asking why they cant leave :slight_smile: or a big welcome title " You can check out any time you like. But you can never leave !" hehehe

What about the main X on the chat window? Because all chats are tabs in the main window.

I think in your case the best would be MIX support. Which lets you get notifications even when not joined to the room. But that would also require a significant development support to add this to Spark (and i think Openfire as well has a limited support). And we only get occasional contributions to Spark development here and there.