-
Notifications
You must be signed in to change notification settings - Fork 8
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
Rollen- und Berechtigungskonzept #165
Comments
Korrektur dazu:
Das stimmt so nicht. Die default-Werte findet man hier. Bei direct rooms sind beide Nutzer jedoch Admins, da dürfen beide alles. |
@mlangguth Die Festlegung von Powerlevel-Templates für Use-Cases halte ich auch für sinnvoll. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ein fachliches Thema, was wir vermutlich noch ausarbeiten müssen:
Konzeptionieren, wer was in welchem Raum darf
Wer darf den Raumnamen ändern? Wer darf weitere User in den Raum einladen? Wer User aus dem Raum werfen? etc.
Dies wird über die power_level festlegungen pro Raum definiert und User bekommen pro Raum power_level zugewiesen. Die Defaultwerte führen dazu, dass jeder alles darf!
Hier braucht es neben der Regelung auf User- und Raumebene auch ein Konzept, welches auf Rollen-Ebene greift (z.B. später in TIM 2.0: Versicherte dürfen keine Raumnamen ändern, wenn sie eingeladen wurde).
Das kann auch durch die TIM-Client-Implementierungen geregelt werden, wäre dann im Verhalten aber proprietär und damit wird es schwieriger übergreifende Prozesse und erwartbare App-Verhaltensweisen festzulegen.
Daher sollte dieser Punkt fachlich erörtert und dann durch gematik-Vorgaben (mindestens mit Spielräumen / Leitplanken) geregelt werden.
The text was updated successfully, but these errors were encountered: