Ziel
Ziel: das Standard-Patrolling benutzbarer machen, ohne Kernsysteme oder Datenbank zu verändern.
Planung und Aufbau
Das Gadget werden wir modular, mit mehreren Unterfunktionen aufbauen um eine spätere Anpassung an ggf. notwendige Upgrades der MediaWiki-Version abzufangen, sowie die Integration und die Weiterentwicklung von Skins nicht zu blockieren.
Modulstruktur & Verantwortlichkeiten
| Modul | Aufgabe | Sichtbarkeit |
|---|---|---|
| Core | Initialisiert Gadget, prüft Benutzerrechte (patrol, rollback), lädt Teilmodule. | Nur für Benutzer mit mindestens einem dieser Rechte. |
| RCView | Fügt in „Letzte Änderungen“, „Beobachtungsliste“, „Änderungen an verlinkten Seiten“ inline Links ein: <br>• ✓ Kontrollieren (Patrolling) <br>• ↩ Zurücksetzen (Rollback) | Nur, wenn Seite ∉ Whitelist und Benutzer die Rechte hat. |
| PageView | Fügt im Seiten-Action-Portlet („Weitere Aktionen“) einen Button „Alle ungeprüften Versionen dieser Seite kontrollieren“ hinzu. | Nur mit patrol-Recht und wenn Seite ∉ Whitelist. |
| HistoryView | Ergänzt im Seiten-Verlauf zwei Mini-Links pro Revision (✓ / ↩) mit denselben Checks. <br>Optional oben „bis hierher alles prüfen“. | Nur mit passenden Rechten. |
| Whitelist Engine | Hält ein Array oder RegEx-Liste mit Seiten/Präfixen, die ausgenommen sind. | Läuft in allen Teilmodulen als Filter. |
| UI Helper | Einheitliche Buttons, Tooltips und Benachrichtigungen (mw.notify). Farbwerte aus Wikonia-Palette. | Global verwendbar. |
Grundlogik
1.Initialisierung
Skizze
→ mw.loader.using(['mediawiki.api', 'mediawiki.util']) → Rechte prüfen mit mw.user.getRights() → Rechteflags setzen: canPatrol, canRollback → DOM-Observer starten (MutationObserver + mw.hook) → Je nach Kontext RCView / PageView / HistoryView aktivieren
2. Whitelist-Check
- Funktion isWhitelisted(title) prüft
- exakte Titel,
- Präfix-Match (z. B. Wikonia:Anträge/),
- RegEx-Match (z. B. alle „Wikonia:Löschantrag/*“).
- Rückgabe → true = keine Aktion.
- RC-Sonderlogik: wenn true → rote !-Marke CSS-seitig ausblenden (display:none), nicht aus dem DOM entfernen.
- Damit können wir die unschönen ! visuell ausblenden, ohne in Vector Observer hineinzufunken.
- Dieser Teil kann später auch in ein globales „UI Rules“-Gadget wandern, ist aber erstmal lokal implementierbar.
3. RC/Watchlist-Interagration (RC View)
- Suche nach DOM-Knoten .mw-patrolled-unpatrolled oder .unpatrolled.
- Eltern-Element finden (z. B. <li> Zeile).
- Innerhalb dieser Zeile nach dem Seitentitel und Editor parsen.
- Wenn nicht Whitelist → füge unterhalb des Textblocks zwei kleine Inline-Links ein:
- ✓ Kontrollieren → api.postWithToken('patrol', { revid })
- ↩ Zurücksetzen → api.postWithToken('rollback', { title, user })
- Bei Erfolg → mw.notify("…markiert …").
Portlet-Button (PageView)
- Prüft Namespace und Whitelist.
- Fügt Link in #p-cactions oder „Werkzeuge“ ein.
- Klick → api.get({ list:'recentchanges', rctitle: pageName, rcshow:'unpatrolled' }) → Schleife patrol.
- Fortschrittsanzeige (mw.notify + Counter).
HistoryView
- DOM-Scan nach li[data-mw-revid] oder a[href*="oldid="].
- Wenn Recht vorhanden und nicht Whitelist → [✓] / [↩] neben Version einfügen.
- Optionaler Header-Button „Bis hierher alles kontrollieren“.
- Kein Anfassen des roten Icons oder des Vector-Observers.
UI-Richtlinien
Das Design sollte sich an unserem CSS orientieren.
| Element | Stil | Farbe (aus wikonia_colors.css) |
|---|---|---|
| ✓ Kontrollieren | kleiner Link oder Pill-Button | --color-success-light |
| ↩ Zurücksetzen | kleiner Link oder Pill-Button | --color-warning-light |
| Hover-State | Unterstreichung + dunklerer Ton | --color-success-dark / --color-warning-dark |
| Notify-Erfolg | grünlicher Hintergrund | --bg-success |
| Notify-Fehler | rötlich | --bg-error |
Entscheidungsnotizen
- Whitelist: bleibt lokal, kann später in globales UI-Gadget verschoben werden, um die Patrollmarkierung für alle zu unterdrücken, da die Seiten nicht wirklich kontrolliert werden..
- Rotes !: wird nicht angefasst, nur per CSS unterdrückt wenn Whitelist matcht.
- Rechteprüfung: immer vor Button-Render, nicht beim Klick.
- Fallback: falls mw.user.getRights() nicht verfügbar ist, kann API-Ping (action=query&meta=userinfo&uiprop=rights) verwendet werden.