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	angemeldet+lernpfadprofi	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' );

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 Seitenbewerten 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-helfer
2. Einführung einer neuen Gruppe zum-autor
3. alle existierende Nutzern in die Gruppe zum-helfer und zum-autor aufnehmen
   • per API
4. ⁉️ mittels $wgNamespaceProtect alle bestehenden Namensräume vor Änderungen schützen mit der Berechtigung ( <NS>-edit )
5. ⁉️ die neue <NS>-edit den Gruppen zum-autor/zum-helfer zuweisen