Benutzer:Christian/Neue Benutzerrechte: Unterschied zwischen den Versionen

Aus ZUM-Unterrichten
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
Zeile 158: Zeile 158:
Problem: '''jeder''' Namensräume (auch durch Extensions neu hinzumkommende) müssen wir erstmal schützen mittels <code>$wgNamespaceProtect</code> und dann die Gruppen zum-helfer und zum-autor berechtigen darauf zuzugreifen.
Problem: '''jeder''' Namensräume (auch durch Extensions neu hinzumkommende) müssen wir erstmal schützen mittels <code>$wgNamespaceProtect</code> und dann die Gruppen zum-helfer und zum-autor berechtigen darauf zuzugreifen.
== Mögliches Vorgehen ==
== Mögliches Vorgehen ==
Das größte Hindernis ist, die Tatsach, dass standardmäßig nahezu alle Namensräume von der Gruppe <code>user</code> editierbar sind und jeder angemeldete Nutzer immer in der Gruppe <code>user</code> ist und auch nicht aus ihr entfernt werden kann. Ziel der Änderungen ist es daher, die meisten Namensräume mittels <code>$wgNamespaceProtect</code> mit neuen Rechten (<code>zum-permission-*</code>) zu schützen und diese neuen Rechte an neue Gruppen (<code>zum-group-*</code>) zu vergeben. Diese neuen Gruppen werden dann von den bisherigen Administratoren an die Nutzer vergeben die die jeweiligen Bedingungen erfüllen.
Das größte Hindernis ist, die Tatsache, dass standardmäßig nahezu alle Namensräume von der Gruppe <code>user</code> editierbar sind und jeder angemeldete Nutzer immer in der Gruppe <code>user</code> ist und auch nicht aus ihr entfernt werden kann. Ziel der Änderungen ist es daher, die meisten Namensräume mittels <code>$wgNamespaceProtect</code> mit neuen Rechten (<code>zum-permission-*</code>) zu schützen und diese neuen Rechte an neue Gruppen (<code>zum-group-*</code>) zu vergeben. Diese neuen Gruppen werden dann von den bisherigen Administratoren an die Nutzer vergeben die die jeweiligen Bedingungen erfüllen.


* Das neue Recht <code>zum-permission-verified</code>.  
* Das neue Recht <code>zum-permission-verified</code>.  
Zeile 169: Zeile 169:
** Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
** Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
** entspricht den Berechtigungen die im alten System der Gruppe <code>user</code> zustanden  
** entspricht den Berechtigungen die im alten System der Gruppe <code>user</code> zustanden  
*Zusätzlich wird E-Mail Bestätigung Pflicht bevor editierrechte ausgeübt werden können
*Zusätzlich werden Editierberechtigungen im Benutzernamensraum auf die eigene Benutzerseite beschränkt
*Absehbar ist, eine weitere Berechtigung für "ZUM-Superautoren" die dann auch andere Benutzerseiten ändern können und evtl. müssen wir das Vorlagenveränderungsrecht auch dort hinschieben.


=== Ablauf ===
# Einführung einer neuen Gruppe <code>zum-group-helfer</code>
# Einführung einer neuen Gruppe <code>zum-group-helfer</code>
# Einführung einer neuen Gruppe <code>zum-group-autor</code>
# Einführung einer neuen Gruppe <code>zum-group-autor</code>

Version vom 5. Mai 2024, 19:35 Uhr

Wie migrieren wir zu dem neuen Benutzerschema?

Beachtenswert

  • Die Nutzergruppe user gibt es nicht in echt
    • Sie ist virtuell im Code von MediaWiki und wird jedem angemeldeten Benutzer zugewiesen.
  • Bestimmte Extensions verändern die Gruppenrechte, nachdem die LocalSettings.php bereits evaluiert wurde. Siehe $wgExtensionFunctions[]
  • Manche Namensräume sind durch spezielle Rechte geschützt, z.B. die Talk-Namensräume durch createtalk statt createpage
    • Das erschwert das Nachdenken im Zusammenspiel mit $wgNamespaceProtection
  • Manche Rechte sind Fähigkeiten, z.B. autopatrol
  • $wgNamespaceProtection funktioniert auf folgende Weise:
    • Man kann damit Namespaces schützen, indem man vorgibt, dass ein Nutzer ein bestimmtes Recht erst haben muss, bevor er editieren kann.
    • Man kann Lese-Rechte damit nicht entziehen
    • Unklar: Vermutlich können Extension-spezifische Sonderrechte damit nicht per Namensraum entfernt werden

Aktuelles Schema

Anmerkung
Diese Aufzählung ist nicht vollständig, sondern nur in Bezug auf das neue Schema bezogen.
anonym angemeldet sysops + co Anmerkung
Lesen bestimmter Seiten
Lesen im Haupt-NS
Schreiben im Haupt-NS
Diskussionseiten sehen unklar ob das nur per UI gemacht ist
Diskussionseiten bearbeiten unklar ob das nur per UI gemacht ist
Editier-Knopf sichtbar
Replacetext nutzen eigenartig, eigentlich sollten das nur SysOps dürfen
Seiten Löschen
Schreiben im Vorlagen-NS ✴️

(Gruppe: lernpfadprofi)

via $wgNamespaceProtection
PageForms bearbeiten unklar, wird eigentlich nicht verwendet

außer auf den Profilseiten, und dort macht es Probleme

Nutzer registrieren


Aktuelle Umsetzung

  • Template Namensraum Editieren ist speziell geschützt
    $wgNamespaceProtection[NS_TEMPLATE] = array( 'edit-template' );

Hinweise

  1. Anonyme Besucher
    • können NICHT schreiben
      $wgGroupPermissions['*']['edit'] = false;
    • können NICHT registrieren
      $wgGroupPermissions['*']['createaccount'] = false;
    • können NICHT den Editierenknopf sehen
      $wgGroupPermissions['*']['viewedittab'] = false;
    • können lesen
      $wgGroupPermissions['*']['read'] = true;
    • können ein paar spezielle Seiten anschauen
      $wgWhitelistRead = array(
         $wgMetaNamespace.':Datenschutz',
         $wgMetaNamespace.':Über '.$wgSitename,
         $wgMetaNamespace.':Impressum'
       );
  2. Angemeldete Benutzer
    • können lesen _Christian: unklar warum das gebraucht wird; sollte ja durch ['*']['read'] = true; bereits erledigt sein_
      $wgGroupPermissions['user']['read'] = rue;
    • können editieren _Christian: unklar warum das gebraucht wird. Ich vermute für VE_
      $wgGroupPermissions['user']['writeapi'] = true;
    • können replacetext verwenden _Christian: das scheint mir nicht so schlau_
      $wgGroupPermissions['user']['replacetext'] = true;
    • kann Seiten löschen _Christian: eigenartig_
      $wgGroupPermissions['user']['delete'] = true;
      $wgGroupPermissions['user']['import'] = true;
      $wgGroupPermissions['user']['importupload'] = true;
      
  3. Lernpfadprofi
    • kann Template Namensraum editieren
      $wgGroupPermissions['lernpfadprofi']['edit-template'] = true;
  4. Sysops und Co
    • kann Template Namensraum editieren
      $wgGroupPermissions['sysop']['edit-template'] = true;


Neues Schema

  1. Anonyme Besucher
    • kann sich selber registrieren
  2. Angemeldete Nutzer + verifizierte E-Mail
    • kann nur eigene Benutzerseite bearbeiten
    • kann Diskussionsseiten bearbeiten
  3. ZUM-Unterrichten Helfer
    • Schüler sind ausgeschlossen
  4. ZUM-Unterrichten Autor
    • Autorencheck
anonym angemeldet Helfer Autor sysops + co Anmerkung
Lesen bestimmter Seiten
Lesen im Haupt-NS
Lesen im Benutzer-NS
Kann Seitenbewertung lesen z.B. Extension:VoteNY
Schreiben im Benutzer-NS nur die eigene Benutzerseite

evtl. via Extension:UserPageEditProtection

Diskussionseiten sehen
Diskussionseiten bearbeiten
Kann Ideen lesen z.B. Extension:InlineComments

Extension:CommentStreams

Kann Ideen posten z.B. Extension:InlineComments

Extension:CommentStreams

Kann Seitenbewertung abgeben z.B. Extension:VoteNY
Schreiben im Vorlagen-NS via $wgNamespaceProtection
Schreiben im Haupt-NS via $wgNamespaceProtection
Seiten Löschen
PageForms bearbeiten
Nutzer registrieren
Editier-Knopf sichtbar
Replacetext nutzen

Problem: jeder Namensräume (auch durch Extensions neu hinzumkommende) müssen wir erstmal schützen mittels $wgNamespaceProtect und dann die Gruppen zum-helfer und zum-autor berechtigen darauf zuzugreifen.

Mögliches Vorgehen

Das größte Hindernis ist, die Tatsache, dass standardmäßig nahezu alle Namensräume von der Gruppe user editierbar sind und jeder angemeldete Nutzer immer in der Gruppe user ist und auch nicht aus ihr entfernt werden kann. Ziel der Änderungen ist es daher, die meisten Namensräume mittels $wgNamespaceProtect mit neuen Rechten (zum-permission-*) zu schützen und diese neuen Rechte an neue Gruppen (zum-group-*) zu vergeben. Diese neuen Gruppen werden dann von den bisherigen Administratoren an die Nutzer vergeben die die jeweiligen Bedingungen erfüllen.

  • Das neue Recht zum-permission-verified.
    • wird an die neue Gruppe zum-group-helfer und zum-group-autor verliehen, sowie an sysop.
    • erlaubt den Zugang zu den Funktionen für das Ideensystem und Seitenbewertungssystem
    • Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
  • Das neue Recht zum-permission-autor.
    • wird an die neue Gruppe zum-group-autor verliehen, sowie an sysop.
    • erlaubt den Editierzugriff auf Haupt- und Vorlagennamensraum (TBD)
    • Vergabe erfolgt manuell durch bestehende ZUM-Unterrichten Administratoren
    • entspricht den Berechtigungen die im alten System der Gruppe user zustanden
  • Zusätzlich wird E-Mail Bestätigung Pflicht bevor editierrechte ausgeübt werden können
  • Zusätzlich werden Editierberechtigungen im Benutzernamensraum auf die eigene Benutzerseite beschränkt
  • Absehbar ist, eine weitere Berechtigung für "ZUM-Superautoren" die dann auch andere Benutzerseiten ändern können und evtl. müssen wir das Vorlagenveränderungsrecht auch dort hinschieben.

Ablauf

  1. Einführung einer neuen Gruppe zum-group-helfer
  2. Einführung einer neuen Gruppe zum-group-autor
  3. alle existierende Nutzern in die Gruppe zum-group-helfer und zum-group-autor aufnehmen
    • per API
  4. ⁉️ mittels $wgNamespaceProtect alle bestehenden Namensräume vor Änderungen schützen mit der Berechtigung ( zum-permission-verified )
  5. ⁉️ mittels $wgNamespaceProtect die Namensräume MAIN, TEMPLATE vor Änderungen schützen mit der Berechtigung ( zum-permission-autor )
  6. ⁉️ die neue Berechtigung zum-permission-verified den Gruppen zum-group-autor/zum-group-helfer zuweisen
  7. ⁉️ die neue Berechtigung zum-permission-autor den Gruppen zum-group-autor zuweisen
  8. Extension:UserPageEditProtection installieren und einrichten
  9. Editieren nur mit bestätigter Email-Adresse
    $wgEmailConfirmToEdit = true;
    $wgEmailAuthentication = true;
  1. edit Berechtigung für user Gruppe entfernen
    $wgGroupPermissions['user']['edit'] = false;
  2. Meilenstein Jetzt können wir die Registrierung öffnen
    • Selbst registrierende Nutzer können nur auf eigener Benutzerseite arbeiten
    • bestehende Autoren können weiterhin überall arbeiten
  3. replacetext wieder auf sysop einschränken
  4. ❓PageForm aus UserProfile mechanismus entfernen