Rocket.chat: Create room permissions for read-only / speak

[marceloschmidt]

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[neurobe]

1+. Read Only Channels: Useful for Channel titles like "Full Manual", "Read Me First", "Help", "Quick Start", "Instructions", Company Info. Also for feeds like "Stock Market Ticker", ...
These could equally be fly-in tabs, not sure which it best.

[mguspero]

Hi everyone, any news about this???

[kreuzebek]

1+, or any way to transform all users in the room to "MUTE"

[mguspero]

This functionality is holding back the implementation in my company!!!

[geekgonecrazy]

@mguspero I'm sorry to hear this. If you would like it built sooner, you are more then welcome to make the changes and open a pull request. We will gladly accept it.

Currently we have other things we are working on. This is an open source project, so we get to things as we have time. :smile:

[marceloschmidt]

@mguspero you are also invited to post a bounty on this. This way you may encourage other developers to take this issue and get it merged, while making a few bucks out of it.

[RichardFoxworthy]

@marceloschmidt Sorry if this is a dumb question, I'm new to this. Should bounties appear automatically in the GitHub Issue comments? Doesn't look like it... This issue now has a bounty on it - https://www.bountysource.com/issues/26744641-create-room-permissions-for-read-only-speak

[RichardFoxworthy]

Read-only channel setup should also include:

• an option to mute all the system messages. When the purpose of the channel is a one-way broadcast of messages from the channel owner or admin, its unnecessary to clutter it up with system messages about who has joined the room etc.
• option to overide the Push Notification settings for all users of the channel - if necessary (say for a important system-wide announcements) the channel owner or admin can set default Push Notification to make sure all members will actually receive those messages.

[lunitic]

Have any progress been done regarding the readonly channels?

[marceloschmidt]

Not yet @lunitic :(

[RichardFoxworthy]

While waiting for Read Only channels to become officially supported, is it possible to set up a default channel, then create a bot or some other API implementation that can auto-mute every new user that registers in the chat service and is enrolled into that channel? That would effectively create a read-only channel that all users would be subscribed to, right?

[geekgonecrazy]

@RichardFoxworthy that sounds like a very plausible solution. We have a way for the bot to call methods on the server. So you would just need to give the bot user the privileges required to mute.

Also possibly would need the bot to be able to subscribe to the channels user list so it can see when people are added. A functionality we don't currently have. But wouldn't be too complicated to add.

[RichardFoxworthy]

Hey @geekgonecrazy that sounds hopeful - could you point me toward any doc or example of how to get a bot to call methods on server?

I already have a Hubot script that can detect when a new user joins the channel, and send them a welcome message.

I am thinking I could extend this functionality to also /mute each new user in the default 'Announcements' channel that I want to support.

[geekgonecrazy]

@RichardFoxworthy You can call methods on Rocket.Chat from the bot like this:

robot.adapter.callMethod('MethodName', args...)

so something like this:

robot.adapter.callMethod('muteUserInRoom', { rid: roomId, username: username });

[insidesmart]

I think we can break the problem to 2 steps to achieve the intended result.

1. Hide the Message Composer for all users except the owner. - This will immediately achieve the intended effect and should be easy to implement in code as well with a small flag in channels & priavte groups. (This is definitely security by obscurity filler to keep most of the crowd from posting messages until we get what we want)
2. Disable posting message in the channel by all users except the owner. - This should be built subsequently with proper checks and permissions systems to block all hackers from posting it.

[geekgonecrazy]

@insidesmart sounds about right. After adding the permission it would be a matter of essentially doing exactly what you just said :+1:

[timkinnane]

Hey, just a ping that we (@4thparty) are addressing this functionality by building an announcements bot for our Rocket.Chat instance. It's not exactly as described in this issue, but will allow us to send one-way messages via a bot to target users/groups. Sending DMs stops users from replying on mass and polluting public channels. We'll control access to the bot using a privileged room where user can tell it to send specific messages, but outside that room it won't work.

I've created a hubot receiver middleware that partially solves the problem by ignoring any direct message replies to the bot. https://github.com/timkinnane/hubot-rocketchat-ignore-direct
Will update again when the rest of it's built.

[mguspero]

Hi everybody, do you have any news for this??? The one way DM for team leaders to users or read only rooms ?? Thanks & Regards!

[timkinnane]

Hey, I've tested and responded to the PR from @alexbrazier. My team was working on a similar solution (we actually commissioned a remote dev) but our approach was quite different. I'd like to get some feedback from core team because if Alex's PR/approach is accepted, we may be wasting our time, or possibly we will work on improving his approach instead of our own.

Our intended solution was to provide a package that would allow:

• Per-room config to mute all users of given role/s, e.g. user and livechat-user - to avoid muting bots and admins.
• Per-room config to disable each notification type.

So you could achieve the result provided by Alex but with two settings instead of one, selecting the roles that cannot post to a room, then selecting to suppress user muted notifications.
That would also allow other configurations, like suppressing user joined / left to be optional.

That would also fix #3641, #3539, #3498, #3418 and partially #2043.

Will share our feature branch as soon as possible.

[engelgabriel]

@RocketChat/core How should we implement this?

[marceloschmidt]

I like @timkinnane suggestions, especially for the ability to suppress user joined / left messages! And so many issues closed! It looks promising!

[alexweissman]

I _think_ this is what I'm looking for with my #github-activity channel - a channel where only my bot can post notifications from our Github integrations.

[phutchins]

I need this as well. We have an #announcements room in which only a few of us post things... Thought about looking into implementing.

[hughlroberts]

Is there a way for the people in the read-only channel to react or acknowledge with an emoji in the read only channel? That's the only missing feature for these read-only channels.

[engelgabriel]

@timkinnane did your guys delivered your suggested implementation? I'd be interested on seen it.

[timkinnane]

@engelgabriel not really, sorry to disappoint :P

We worked with @alexbrazier to align his PR with some of our suggestions, which is what made it into core. We haven't yet followed up the idea of muting types of system messages. I noticed that there's settings to disable room join/leave messages globally, but I've considered that could be bad UX because users may be unaware of who is listening (or not) in channels if people can silently join and leave.

It would be nice to disable some other notification messages like room setting changes (topic changes etc), as they can clutter a room, but its not critical. As a temporary hack, I've actually written a command line maintenance tool, it provisions our instances, creating rooms, adding users, setting topics etc, then cleans up after itself deleting all system notices straight from mongo - leaving a clean message history for new users. The query for that is:

db.collection('rocketchat_message').find({$or: [{t:'uj'}, {t:'ul'}, {t:'ru'}, {t:'au'}, {t:'room_changed_description'}, {t:'room_changed_topic'}, {t:'room_changed_privacy'}, {t:'r'}]})

As you can see there's some inconsistency in the creation of different types of system notices, I've got #4016 on my radar as part of this problem too. Before adding controls for individual message types, it would be good to bring the outliers in line, making it possible to easily query all system message types without missing anything.