Request: Set permissions of users invited to Invite-Only Stream #425

Open
Wylfenrix opened this Issue Jan 14, 2016 · 4 comments

Projects

None yet

5 participants

@Wylfenrix

It'd be helpful if I could set different levels of permissions for users that I invite to the Stream I've created.

Permissions could be various levels of most strict to least strict, such as:
Most Strict - User can view chat, but cannot reply to chat. User cannot add new members to this Stream, and cannot create new topics (essentially letting the Stream or topic creator use it as an "announcements" channel that can't be cluttered up with chat).
Least Strict - User can reply to chat, create new topics, and remove or add other users to this Stream (essentially identifying a user as having all the privileges the Stream "creator" has).

It might be easier and more clear to implement this by having different user roles such as "Creator", "Administrator", "Moderator", "User", and "Bot".

If there's any additional questions about this, please let me know. Thanks!

@timabbott
Member

Agreed that we probably will need to do some form of stream permission levels eventually. @wdaher do you have ideas for what the right model structure should be here?

@wdaher
Contributor
wdaher commented Jan 21, 2016

Truthfully, not really - I'd probably look at e.g. the permission model in something like Google Groups for inspiration — the roles @Wylfenrix seem reasonable: e.g. can talk, can add members to stream, can modify members in stream, can create new topics, etc.

Having said that, I'd encourage us not to implement this right now — it increases the product's complexity significantly and I don't think the average user really wants or needs it.

@timabbott timabbott added this to the 2016 roadmap milestone Apr 29, 2016
@acrefoot
Contributor

Hey @timabbott, @krtkmj is looking into potentially picking this up.

Is @wdaher's assessment still right? I noticed that you've added it to the 2016 roadmap.

@timabbott
Member

Cool. I like the permissions model approach discussed above. Here's how I'd sequence things:

(1) Design an implement the interface for storing and accessing stream permissions. I think this should probably be stored as attributes on the Subscription object, since that's our already existing (user, stream) pair object. We should consider doing something similar to UserMessage.flags, where we use a BitField called 'permissions' for the attributes. This should be its own commit (or commits), setting up the infrastructure for permissions.
(2) Create a stream_admin permission level, giving admin permission for just that stream. Initially I'd just make the stream_owner permission set via a management command so that we can focus on building the infrastructure.
(3a) Add routes to add/remove permissions, and a UI for changing permissions of users on a stream (probably will involve some reworking on the /#streams page UI).
(3b) Add additional permission levels. This can be started on once we have (2) done; we can implement the permissions levels and add tests that they work correctly, even without a UI for controlling them.

In terms of the actual permissions, it seems like we will eventually have something like these levels:

  • Stream Administrator (can do anything a realm administrator can do with the stream, manage members, etc.).
  • Moderator (can add/remove, but not change owners or moderators. Probably would skip for now until we have a clear need).
  • Regular member (can send/receive anything on a stream).
  • Read-only (can only read messages on the stream).

(we will likely want to think through the names more, and might add a few more).

@timabbott timabbott modified the milestone: Zulip roadmap, Old roadmap Nov 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment