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!
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?
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.
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.
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:
(we will likely want to think through the names more, and might add a few more).