DevOps Core

DevOps Core ist die fachliche Grundlage der DevOps-Suite: Projekte, Rollen, Naben-Navigation und Merkmalschalter, auf denen alle DWDO-Pakete aufsetzen. Ein Projekt ist dabei kein Datensatz, sondern ein Namensraum. Gedacht ist das Paket für Verwalter, die Projekte und Rollen einrichten, und für Plugin-Entwickler, die ein eigenes Paket in die Suite einhängen.

Schnelleinstieg: Das erste Projekt anlegen und öffnen — der kürzeste Weg zum ersten Ergebnis, in drei Schritten.

Projektwurzel festlegen → Rollen zuordnen → Naben prüfen

Das Fundament der DWDO-Schicht: Was ein Projekt ist, wer darin was darf, und wie die Navigation innerhalb eines Projekts aussieht. Jedes DWDO-Paket baut darauf auf, statt seine eigene Vorstellung davon mitzubringen.

Das Paket rendert von sich aus keinen eigenen Bildschirm. Es registriert fünf Dienste an der Registratur von Core Plugin und stellt sie damit allen übrigen Paketen zur Verfügung.

Alle fünf sind über registerFactory() angemeldet: Ein Objekt entsteht erst beim ersten get() auf seine Kennung. Eine Anfrage, die kein DWDO-Projekt berührt, baut also keines davon.

• Ein Wiki soll mehrere Projekte führen, die einander nicht sehen sollen, ohne dass jedes eine eigene Rechteverwaltung mitbringt.
• Mehrere DWDO-Pakete sollen dieselbe Vorstellung davon teilen, was „das aktuelle Projekt„ ist.
• Eine Projektleiste soll nur die Einträge zeigen, deren Bildschirme in dieser Installation überhaupt existieren.
• Ein Fremdpaket soll eine eigene Nabe oder eine eigene Rolle beisteuern können, ohne dass wkdocore davon wissen muss.

Nicht Gegenstand dieses Pakets: die Bildschirme selbst. Arbeitselemente, Abfragen, Pipelines und Datenhaltung liegen in eigenen Paketen (siehe Siehe auch).

Ein Projekt ist zuallererst ein Namensraum unterhalb der Projektwurzel. Damit erbt es alles, was DokuWiki für Namensräume kann — ACL, Suche, Sicherung, Versionierung —, ohne dass irgendetwas davon nachgebaut werden müsste.

projectroot ist nicht auf einen festen Namensraum festgelegt. Enthält der Wert den Platzhalter {lang}, löst action_plugin_wkdocore::roots() ihn einmal je Sprache aus projectlangs auf und liefert entsprechend viele Wurzeln zurück.

Warum das mehr ist als Ordnungsliebe. Eine Vorlage, die die Anzeigesprache aus dem führenden xx:-Abschnitt der Seitenkennung ableitet, bekommt von einer Seite unter einer sprachlosen Wurzel nichts. Ihre Aufwärtssuchen — Seitenleiste, Thema — verlassen dann die Sprache und greifen ins ganze Wiki. Der Platzhalter ist der Weg, Projektseiten innerhalb der Sprachnamensräume zu führen (de:projects:acme:…) statt in einer sprachlosen Wurzel daneben.

Ausgeliefert wird projectroot = projects, also ohne Platzhalter. Das ist Absicht: Eine bestehende Installation behält ihre Anordnung beim Aktualisieren. Der Platzhalter ist eine Entscheidung, die der Betreiber trifft — und er trifft sie einmal, denn eine nachträgliche Umstellung ist ein Umzug des Seitenbestands, kein Wechsel einer Einstellung.

Über die DokuWiki-ACL legt sich eine Rollenschicht aus Gruppen der Form @dwdo_<projekt>_maintainers / _contributors / _readers. Das Präfix dwdo_ ist über roleprefix einstellbar.

Die Rollen ersetzen die ACL nicht, sie liegen darüber: Wer eine Seite nach ACL nicht lesen darf, sieht sie auch mit hoher Rolle nicht. Die Rolle entscheidet, welche Funktionen eines Projekts jemand bedienen darf.

Role::atLeast() vergleicht zwei Rollen über ihre Stufe. Steht eine von beiden nicht auf der Leiter, liefert der Vergleich false — es wird weder eine Ausnahme geworfen noch eine Vorgabestufe angenommen.

Das ist eine bewusste Sicherheitsentscheidung: Eine Nabe oder ein Merkmal, das auf einen unbekannten Rollennamen abgesichert ist — Tippfehler, oder eine Rolle aus einem Paket, dessen defineLevel()-Aufruf nie lief —, wird verborgen, nicht freigegeben.

Die Leiste innerhalb eines Projekts. HubRegistry::defaults() liefert acht Naben:

hub.settings ist die einzige Nabe, die nicht bei reader und Leserecht steht. Sie verlangt maintainer und Bearbeitungsrecht. Beide Prüfungen laufen unabhängig voneinander, ausdrücklich als gestaffelte Absicherung.

Vier der acht Naben zeigen auf einen Bildschirm, den ein eigenes Paket besitzt — sie verschwinden, wenn dieses Paket fehlt oder abgeschaltet ist. Die anderen vier zeigen auf gewöhnliche Wiki-Seiten, die ein Team selbst schreibt; sie brauchen kein Paket und erscheinen deshalb immer.

„Installiert„ heißt dabei installiert und eingeschaltet: Die Prüfung läuft über plugin_isdisabled(), und DokuWiki meldet ein unbekanntes Paket als abgeschaltet. Ein im Erweiterungsmanager deaktiviertes Paket ist damit genauso unerreichbar wie ein fehlendes — und seine Nabe verschwindet in beiden Fällen.

Der Grund, warum eine Nabe ohne Bildschirm verschwindet statt ins Leere zu führen, steht im Code ausgeschrieben und gehört hierher: Eine sichtbare Nabe, die nirgendwohin führt, kostet einen Klick und bringt dem Leser bei, dass die Navigation lügt. Eine ausgeblendete sagt „hier nicht“, und das stimmt.

FeatureFlags::resolve() entscheidet je Schlüssel in dieser Reihenfolge; die erste zutreffende Stufe gewinnt:

1. Projektbezogene Übersteuerung — gewinnt immer, auch über ein fehlendes Paket. Grund: reserved
2. Paket meldet sich als nicht verfügbar — schaltet ab, gleich was die Vorgabe sagt. Grund: plugin-missing
3. Wiki-weite Vorgabe aus disabledhubs — Grund: default bzw. suite-disabled
4. Keine Stufe hat etwas gesagt — der Schalter steht an. Grund: default

Die Naben führen zu den Bereichen eines Projekts. Wer zuerst wissen muss, welche Projekte und Repositories es überhaupt gibt, braucht eine Ebene davor — dafür gibt es zwei Verzeichnisdienste und drei Syntaxbausteine.

Das Projektverzeichnis führt vier Quellen zusammen — vorgesetzte Kürzel, den Namensraum-Durchlauf, gespeicherte Projektdatensätze und das Ereignis WKDOCORE_PROJECT_DISCOVER. Es beantwortet Einzelabfrage und Auflistung aus derselben Menge: Ein Projekt, das die Liste nicht zeigt, ist auch über die Einzelabfrage nicht nachweisbar. Andernfalls wäre die Abfrage ein Auskunftsmittel über Projekte, die der Fragende nicht sehen darf.

Alle vier rufen nocache(): Ihre Ausgabe hängt vom Konto ab, und eine zwischengespeicherte Seite zeigte dem nächsten Besucher die Auswahl des vorigen.

{{wk:explore>}} ist keine dritte Umsetzung derselben Listen, sondern ruft die beiden anderen Bausteine auf. Filter, Beschriftungen, Leerzustände und die Berechtigungsprüfung gibt es deshalb genau einmal. Die Abfrageparameter beißen sich nicht: Die Projektliste liest pq/pscope/pstatus, die Repository-Liste rq/rp/ro, und q bleibt der Volltextsuche des Wikis. Beide Filter arbeiten daher auf einer gemeinsamen Seite unabhängig voneinander, und eine gefilterte Ansicht ist eine Adresse, die sich weitergeben lässt.

Option: size=<n> setzt die Seitengröße der Repository-Tabelle. Die Repository-Liste steht in diesem Baustein fest auf alle Projekte — sie ist hier der projektübergreifende Einstieg, auch wenn die Seite in einem Projektnamensraum liegt.

{{wk:repos>}} richtet sich nach der Seite, auf der es steht. Innerhalb eines Projekts zeigt es die Repositories dieses Projekts, außerhalb alle. Das war einmal umgekehrt, und so entstand eine Seite, die Die Repositories dieses Projekts überschrieben war und die aller Projekte auflistete. Das Gegenmittel war, das Projektkürzel von Hand einzutragen: ableitbar aus dem Namensraum der Seite, bei einem Tippfehler still zu einer leeren Liste führend, und etwas, das eine schreibende Person wissen muss statt etwas, das die Seite über sich selbst weiß. Aus demselben Grund setzt {{wk:explore>}} oben ausdrücklich project=all: ein Einstieg, der die ganze Landschaft zeigen soll, darf das nicht davon abhängig machen, wo er zufällig liegt.

Beide Listen verweisen neben ihrer Ergebniszeile auf die geschriebene Anleitung zu ihrem Bildschirm, und zwar nur dann, wenn es diese Seite auf dieser Installation wirklich gibt. Eine nicht geschriebene Anleitung kostet den Verweis und erzeugt niemals einen toten Link.

do=wkdocore_members&project=<kürzel> zeigt, wer in einem Projekt welche Rolle hat, und gibt sie aus. Kein Bildschirm der Wiki-Verwaltung, sondern eine eigene Aktion — und das ist der entscheidende Unterschied: Der Verwaltungsbereich prüft den wikiweiten Manager-Status, dieser Bildschirm prüft die Projektrolle. Ein Maintainer kommt hinein, ohne Wiki-Administrator zu sein; ein Wiki-Administrator, der in keinem Projekt eine Rolle hat, kommt trotzdem hinein.

Die Grenze steht in Domain/ProjectMembership, nicht in der Oberfläche: Der Bildschirm bietet eine Stufe, die der Betrachter nicht vergeben darf, gar nicht erst an, und die Prüfung weist eine von Hand gebaute Absendung derselben Stufe ebenfalls ab. Zwei Ebenen, weil die erste Auszeichnung ist und Auszeichnung keine Rechteprüfung.

Eine Rollenvergabe ersetzt die bisherige Stufe, statt sie zu ergänzen: Die Rollenauflösung nimmt den ersten Treffer von oben, eine zusätzliche schwächere Gruppe entscheidet also nichts mehr und wäre nur eine Angabe, die der Wirklichkeit widerspricht. Bereits bestehende Doppelungen werden je Zeile benannt, aber nicht ungefragt entfernt.

Der Anfrage-Verteiler von wkrequest zeigt für ROLE_REQUEST und ACCESS_REQUEST auf diesen Bildschirm. Vorher zeigte er auf die Benutzerverwaltung des Wikis — weshalb jede Mitgliedsanfrage jedes Projekts bei einer einzigen Person endete, unabhängig davon, wer das Projekt betreut.

{{wk:repos>}} blendet Spalten aus, die keine Zeile füllen kann. Der Standardbranch steht zur Verfügung, weil ihn eine einzige Sammelauskunft je Verbindung liefert — bei 61 eingebundenen Repositories sind das vier Anfragen, nicht 61, und die Antwort wird zwischengespeichert. Sprache und letzte Änderung würden je Zeile eine eigene Anfrage kosten; die Einhängequelle lässt sie deshalb weiterhin offen, und die Spalten erscheinen gar nicht erst, statt leer zu bleiben.

Acht Einstellungen, im Konfigurationsmanager unter plugin » wkdocore. Die Spalte Vorgabe nennt den ausgelieferten Wert, nicht den auf dieser Installation gesetzten.

Jeder Wert wird durch cleanID() normalisiert, leere Einträge fallen weg, Doppelungen werden zusammengefasst. Eine Kommaliste mit Leerzeichen um die Einträge ist also zulässig.

Fünf Stellen, an denen ein Fremdpaket beitragen kann, ohne dass wkdocore es kennen muss:

Keines der drei Ereignisse hat eine Vorgabehandlung auf Kernseite: Die Behandler tragen ihren Beitrag unmittelbar in die geteilte Registratur ein.

Eine Repository-Quelle liefert fertig geprüfte Zeilen. Der Vertrag verlangt vier Dinge: Sie filtert selbst nach Berechtigung, sie wirft nie, sie nennt nur Repositories, für die sie einstehen kann, und die gemeldeten Fähigkeiten sind die tatsächlichen. Damit braucht der Explorer keinen Sonderfall je Backend — wkdoadogit erscheint darin durch Installation, nicht durch eine Codeänderung in der Projektoberfläche.

?do=wkdocore_diag zeigt den aufgelösten DwdoContext als JSON: aktives Projekt, Rolle des angemeldeten Nutzers, sichtbare Naben, Merkmalschalter samt Grund je Schlüssel, Nutzername und Administratorkennzeichen. Das ist die schnellste Antwort auf „warum sehe ich diesen Menüpunkt nicht“ — der Grund steht wörtlich da (reserved, plugin-missing, suite-disabled, default).

Die Prüfung auf die Registratur läuft entenartig über method_exists(), nicht über eine Typangabe. Core Plugin ist eine Laufzeit-Abhängigkeit, die über plugin_load() kommt, keine harte Einbindung — deshalb muss der Code eine fehlende oder fremde Nutzlast vertragen.

• Core Plugin — die Dienstregistratur, an der die fünf dwdo.*-Dienste hängen
• DevOps Storage Plugin — die Datenhaltung samt dwdo_projects und ihren Fremdschlüsseln
• Azure DevOps Connector — die Verbindung zu Azure DevOps
• Boards, Dashboard, Pipelines, Queries, Work Items — die Pakete hinter den vier paketgebundenen Naben
• wkfluentui — die Schale, in deren rechte Rail die Nabenleiste zeichnet
• wkdoadogit — die Repository-Quelle, die die eingebundenen Git-Repositories in den Explorer einträgt
• Projekte und Quelltext — dieselben Bausteine aus Sicht der Lesenden, mit den Anleitungen

Paket: wkdocore
Verzeichnis: lib/plugins/wkdocore/
Autor: Wolfgang van der Stille Wolfgang.van.der.Stille@gmail.com (The White Knight Labs)
Lizenz: GPL-2.0-only