Benutzer:Christian/Neue Benutzerrechte

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