Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow roles #87

Open
Biep opened this issue Feb 27, 2020 · 8 comments
Open

Allow roles #87

Biep opened this issue Feb 27, 2020 · 8 comments
Labels
A-Roles O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement

Comments

@Biep
Copy link

Biep commented Feb 27, 2020

Many groups have members of different kinds, such as teachers and pupils, or gurus and n00bs, or researchers, patients and caregivers. In such cases it can be useful to make those groups visually distinct - especially in situations where a mix-up might be harmful, as in a non-caregiver posing as one and starting to solicit private information, or a non-teacher prankster giving false instructions.
Currently a work-around is possible using flair, but if room administrators could simply assign members to the various classes, that would be much better. Once communities are there, as 'super-rooms', such assignment could also be done on that level.
Remark that this is fully orthogonal to power levels - though once those become multidimensional, one of their dimensions could be used to indicate roles.
Ideally the roles should be visible in the list to the right - which might even be sorted by role, akin to the way tags sort the room list to the left.

@Biep
Copy link
Author

Biep commented Mar 2, 2020

This is not a suggestion specifically for communities - I just mentioned that such rôles could be assigned at all hierarchical levels: from threads to communities. (In fact, if the hierarchy is implemented properly, this would automatically become possible: whatever works for rooms should keep working for rooms of all levels.)
These rôle tags should also be addressable: if there is a tag 'teacher', then a mention of '@teacher' should be interpreted as a mention for all members with the tag 'teacher'.

@turt2live
Copy link
Member

We just use labels like that so we can find it in the future. It's not to say it will be solved with communities, just that it's a case to consider while working on communities.

@Biep
Copy link
Author

Biep commented Mar 2, 2020

OK. Thanks!

@HansJK
Copy link

HansJK commented Apr 2, 2020

A role system is far superior to a hierarchical level one for larger communities. This is why Discord have such a powerful moderation tools and bots. Hope to see this with Community 2.0.

@niquewoodhouse niquewoodhouse transferred this issue from element-hq/element-web Jan 7, 2022
@niquewoodhouse niquewoodhouse added T-Enhancement A-Roles O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround labels Jan 7, 2022
@ArtexJay
Copy link

This is a must/dealbreaker for me and my group

@HarHarLinks
Copy link

Some Element derivatives such as BundesMessenger implement something like this using different approaches.

@marcgallego
Copy link

Any updates on this?

@Biep
Copy link
Author

Biep commented Nov 8, 2024

Alas, not to my knowledge. It would be a huge improvement for certain common potential use cases.
I think implementation could start very minimally - assign to each room member a list of labels, and allow members with a certain minimum power level to assign and retract such labels.
Then clients could use that so show roles in the room member list, and if requested to sort that list by rôle. They could also consider any mention of a role held by the logged-in user as a mention of that user, and present messages accordingly (e.g. in red)
And so on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Roles O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Enhancement
Projects
None yet
Development

No branches or pull requests

7 participants