Zugangssteuerung und Moderation (UNB2)

Letzte Aktualisierung: 2007-11-02

Zugangssteuerung

Die Zugangssteuerung soll primär über Schlüssel erfolgen. Schlüssel sind systemweit eindeutige 32-bit-Zahlen. Jede Benutzer-ID ist ein Schlüssel, jeder Benutzer hat somit seinen persönlichen Schlüssel. Dass diese Schlüssel anstatt fortlaufend als fünfstellige (oder längere) Zufallszahl generiert werden, ist mehr ein optischer Faktor. Um mehreren Benutzern den gleichen Schlüssel zuzuweisen, um gemeinsame Berechtigungen zu ermöglichen, werden weitere „virtuelle Benutzer“ angelegt, die sich nicht anmelden können, deren Schlüssel aber anderen Benutzern zugewiesen werden kann. Dieses Konzept ersetzt prinzipiell die Gruppenzugehörigkeit von Benutzern, wobei Gruppen selbst wieder „Benutzer“ (ohne Anmeldemöglichkeit) sind.

Ein Beitrag enthält jeweils eine Schlüsselliste für Lese-, Änderungs- und Antwortberechtigungen. Wenn diese Schlüsselliste nicht leer ist, wird die entsprechende Aktion nur einem Benutzer gewährt, der über einen dieser Schlüssel in seinem Schlüsselbund verfügt. Die Listen für Lese- und Antwortberechtigung sind normalerweise leer, die Änderungs-Schlüsselliste enthält normalerweise nur den Schlüssel des Autors und den „aller Moderatoren“. Sollen Beiträge wie in einem CMS oder Wiki üblich von mehreren Benutzern geändert werden können, werden weitere Schlüssel zu dieser Liste hinzugefügt bzw. von ihr entfernt.

Ein Tag verfügt ebenfalls über zwei Schlüssellisten. Die eine legt die Nutzungsberechtigungen des Tags fest. Ist diese Liste nicht leer, darf das Tag nur von Inhabern eines passenden Schlüsseln in Beiträgen gesetzt werden. Beim Antworten auf einen Beitrag werden i. d. R. alle im Ursprungsbeitrag gesetzten Tags als Vorgabe für die Antwort übernommen. Tags, für die man keine Berechtigung besitzt (z. B. etwas wie „Offizielle Ankündigung“), sind davon natürlich ausgenommen. Die Schlüsselliste neuer Tags ist normalerweise leer. Aus den Tag-Nutzungsberechtigungen ergeben sich weitere Einschränkungen auf Beiträge, die das Tag verwenden: Diese Beiträge dürfen nur von Benutzern verändert werden, die zusätzlich über die Nutzungsberechtigung des Tags verfügen. (So lassen sich wichtige Inhaltsseiten zusätzlich vor unerwünschten Veränderungen schützen.) Die zweite Schlüsselliste wird dafür verwendet, um die Leseberechtigung für Beiträge, die das Tag verwenden, einzuschränken. Auch hier gilt: Ist die Liste nicht leer, dürfen nur Benutzer mit passendem Schlüssel die entsprechenden Beiträge lesen. (Das entspricht im Wesentlichen den „Forenberechtigungen“ anderer Systeme.)

Damit Moderatoren (also Benutzer, die den „Alle Moderatoren“-Schlüssel besitzen) auch alle Beiträge einsehen und verändern können, haben sie die Möglichkeit, alle Schlüssellisten zu bearbeiten. Ob es hierfür Einschränkungen geben soll, ist noch nicht geklärt. Andernfalls werden die Schlüssellisten vom Beitragsautor festgelegt. Tag-Schlüssellisten können nur von Moderatoren verändert werden, die auch die einzigen sind, die Tags generell verwalten können.

Moderation

Ein neuer Beitrag oder eine neue Beitrags-Revision muss zunächst genehmigt werden. Bis dahin können nur der Autor und ein Moderator den Beitrag bzw. die betreffende Version sehen. Alle anderen sehen den Hinweis „Noch nicht genehmigter Beitrag/Version“. Ein Moderator kann noch ungenehmigte Beiträge anderer genehmigen.

Ein vertrauenswürdiger Benutzer (durch einen weiteren Schlüssel identifiziert) kann seine eigenen Beiträge/Änderungen u. U. selbst genehmigen. Das gilt allerdings nicht für Beiträge, deren Referenzen das Flag EnforceApproval enthalten. Dieses Flag wird rekursiv in allen primären Referenzen gesucht, wobei die Suche nach Erreichen eines Diskussionseinstiegspunkts abgebrochen wird. Durch diese Einstellung lassen sich „Themen“ effektiv sperren: Antworten darauf müssen immer erst genehmigt werden, sonst werden sie nicht öffentlich sichtbar. Das EnforceApproval-Flag kann nur von Moderatoren gesetzt werden. Da derjenige, der das Flag setzt, auch das Interesse hat, die Antworten zu prüfen, würde ansonsten das Problem entstehen, dass Nicht-Moderatoren die Antworten genehmigen können wollen, was nicht mit der allgemeinen Moderationsidee vereinbar ist.

Datenstruktur

Mitteilung

  • MitteilungID
  • Autor (Verfasser der Mitteilung = Schlüssellistenverwalter)
  • Primäre Referenz (siehe Mitteilung.ID, optional)
  • Weitere Referenzen (in eigener Relation)
  • Revisionen (in eigener Relation)
  • Zugewiesene Tags (in eigener Relation)
  • Diskussionseinstiegspunkt?
  • Seitenname (Wiki-style, optional)
  • Leseschlüssel (ID der Schlüsselliste für Leseberechtigung, optional)
  • Änderungsschlüssel (ID der Schlüsselliste für Änderungsberechtigung, optional)
  • Antwortschlüssel (ID der Schlüsselliste für Antwortberechtigung, optional)
  • Moderations-Flags (EnforceApproval? Locked? Hidden?)
  • Suchoptimierter Inhalt (Reintext-Ausgabe der neuesten genehmigten Version, für die Suche verwendet)
  • Zeitpunkt, zu dem diese Mitteilung zuletzt zu bearbeiten begonnen wurde (verwendet für Warnmeldungen an weitere Editoren)

Mitteilungsreferenz

  • MitteilungID
  • Referenz (Mitteilung, auf die sich MitteilungID bezieht)

Mitteilungs-Revision

  • MitteilungID
  • Revisionsnummer
  • Datum/Zeit
  • Autor (Verfasser dieser Revision, also des eigentlichen Inhalts)
  • Titel (optional)
  • Inhalt (hier steht die eigentliche Mitteilung drin)
  • HTML-Cache (enthält übersetzten Inhalt, optional, abgeleitete Information)
  • Zusammenfassung (der Änderungen, ggf. auch „Bearbeitungsgrund“)
  • Moderationsstatus (WaitingForApproval / Approved / Locked)

Tag

  • TagID
  • Name
  • Übergeordnetes Tag (für hierarchische Beziehungen/Darstellung, optional)
  • Bedeutung (TODO)
  • Beschreibung (gibt Hinweise zur Verwendung des Tags, erklärt Bedeutung, optional)
  • Nutzungsschlüssel (ID der Schlüsselliste für Nutzungsberechtigung, optional)
  • Leseschlüssel (ID der Schlüsselliste für Leseberechtigung der Beiträge, optional)
  • Flags (NotSelectable? Invisible? UserData?)

Mitteilungs-Tag

  • MitteilungID
  • TagID
  • TagData (optional)

Benutzer

  • BenutzerID (Schlüssel)
  • Weitere Schlüssel (weitere zugeordnete Schlüssel, optional)
  • VCard (in eigener Relation)
  • Anmeldedaten... (z. B. Benutzername und Kennwort, oder CardSpace-ID etc. – noch nicht festgelegt, optional)

Benutzer-VCard

  • BenutzerID
  • Typ (Realname, E-Mail, Geburtstag, ICQ, ... – als Text-Abkürzung gespeichert, damit erweiterbar)
  • Daten
  • Sichtbarkeit (Öffentlich, Intern = nur für registrierte Benutzer, Vertraulich = nur für vertrauenswürdige Benutzer, Privat = Versteckt)

Schlüsselliste

  • ID
  • Schlüssel (siehe Benutzer.ID)