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

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