Eine Frage kommt über das Feedback-Formular immer wieder herein, und zwar fast wörtlich gleich: Jemand hat die Instanz selbst eingerichtet — als Träger, nicht als Keyholder — und möchte nun seine Keyholderin dazuholen. Wie lädt man sie ein, und wie gibt man ihr die Rechte?
Die kurze Antwort: Eine Einladung per E-Mail gibt es nicht. Konten werden von Hand angelegt. Die längere Antwort ist die interessantere, weil es nicht eine richtige Einrichtung gibt, sondern zwei — und weil die naheliegende dritte Variante besser funktioniert, als ihr Ruf vermuten lässt.
Keine Einladung, sondern ein Konto
Ein Konto besteht aus Benutzername, Passwort, E-Mail-Adresse und Rolle. Anlegen kannst du es auf zwei Wegen, die zum selben Ergebnis führen: im Portal unter Dashboard → deine Instanz → Tracker-Benutzer, oder in der Instanz selbst im Keyholder-/Admin-Bereich unter Benutzer → Neuer Benutzer. Über das Portal lassen sich zusätzlich Rollen umstellen und Passwörter zurücksetzen, ohne dass du dich in der Instanz anmeldest.
Die Zugangsdaten gibst du danach persönlich weiter — über den Kanal, den ihr ohnehin nutzt. Das Passwort ändert sie anschliessend selbst in ihren Einstellungen; das alte Passwort wird dabei nicht verlangt. Das ist eine bewusste Produktentscheidung: Wer angemeldet ist, hat sich bereits ausgewiesen.
Damit ist das Konto da. Die eigentliche Frage ist die nächste — welche Rolle es tragen soll.
Drei Rollen, zwei Rollenwerte
Der Tracker kennt drei Rollen: den Keuschling, der seinen Verschluss dokumentiert, den Keyholder, der Vorgaben setzt und kontrolliert, und den In-App-Admin, der Benutzer verwaltet. Was die drei inhaltlich unterscheidet, steht ausführlich in Muss ein Keyholder sich selbst tracken?.
Im Konto selbst stehen davon nur zwei Werte: „user" und „admin". Das ist kein Widerspruch, sondern der Kern der ganzen Frage — Keyholder ist keine Rolle, die im Konto steht, sondern eine Beziehung zwischen zwei Konten. Wer Keyholder ist, ergibt sich also entweder aus der Admin-Rolle, die ohnehin alles sieht, oder aus einer ausdrücklichen Zuweisung.
Genau daraus folgen die beiden sinnvollen Einrichtungen.
Variante 1: Sie steuert, du verwaltest
Deine Keyholderin bekommt ein Konto mit der Rolle „user" und wird dir anschliessend zugewiesen: Benutzer → dein Konto → Einstellungen → Keyholder. Damit hat sie die vollen Keyholder-Befugnisse über dein Konto — Kontrollen anfordern, Sperrzeiten setzen, Aufgaben stellen, Trainingsziele vorgeben, das Strafbuch führen — aber keinen Zugriff auf die Verwaltung der Instanz.
Zuweisen kann das nur ein Admin, also du selbst, solange du noch Admin bist. Die Benutzerverwaltung bleibt in dieser Variante folglich bei dir. Das ist der ehrliche Preis: Sie führt dich, aber die technische Kontrolle über die Instanz liegt weiterhin bei dem, der geführt wird. Für viele Konstellationen ist das genau richtig — die Dynamik lebt von der Vereinbarung, nicht von der Rechteverteilung in einer Datenbank.
Der praktische Vorteil dieser Variante: Sie hängt an der Zuweisung, nicht an einer Rolle. Sie funktioniert deshalb unabhängig davon, welche Rolle du selbst trägst, und übersteht es, wenn später jemand an den Rollen dreht.
Variante 2: Sie übernimmt, du wirst Träger
Hier bekommt sie ein Konto mit der Rolle „admin", oder ihr bestehendes Konto wird umgestellt: Benutzer → die Person → Einstellungen → Rolle. Ein Admin sieht alle Konten der Instanz; eine zusätzliche Zuweisung braucht es dafür nicht.
Anschliessend stufst du dich selbst auf „user" zurück, auf demselben Weg über dein eigenes Konto. Das ist ausdrücklich vorgesehen und erlaubt, solange mindestens ein weiterer Admin bleibt. Der letzte Admin kann sich nicht zurückstufen — sonst käme niemand mehr in den Adminbereich, und die Instanz wäre verwaltungslos. Diese Sperre greift in der Instanz wie im Portal.
Die Reihenfolge ist damit fest: erst ihr Konto auf „admin", dann du auf „user". Umgekehrt geht es nicht.
Und wenn ihr beide Admin bleibt?
Das ist der Fall, den die meisten aus Versehen herstellen: Die Keyholderin wird zum Admin gemacht, der Träger bleibt es ebenfalls. Und das funktioniert — besser, als man erwarten würde.
Eine Keyholderin mit Admin-Rolle sieht in der Übersicht jede Karte der Instanz, auch die eines Trägers, der selbst Admin ist. Sie öffnet seine Detailseite und kann jede Direktive erteilen: Kontrollen, Sperrzeiten, Aufgaben, Urteile im Strafbuch. Die Befugnisse hängen an ihrer Rolle, nicht an deiner.
Zwei Dinge fehlen trotzdem.
Das erste sind die Zeilen im Keyholder-Posteingang. Für einen Träger mit Admin-Rolle legt die App keine an, weil es für sie keinen Leser gäbe — der Posteingang führt Träger mit Admin-Rolle nicht. Wichtig dabei: Die Meldung geht nicht verloren. Mail und Push laufen unverändert weiter; es entfällt allein die nachlesbare Zeile im blauen Posteingang.
Das zweite ist die Startseite. Ein Träger mit Admin-Rolle lässt sich nicht als Startseite nach dem Login festlegen — sie muss ihn also jedes Mal über die Übersicht ansteuern.
Beides sind Unbequemlichkeiten, keine Blockaden. Die eigene Rückstufung auf „user" ist damit Aufräumen und Posteingang, nicht die Voraussetzung dafür, geführt zu werden. Wer die Rolle behalten möchte, kann das also tun — und wer sie ohnehin nicht braucht, gibt sie ab und bekommt den Posteingang dazu.
Das Portal-Konto bleibt, wo es ist
Eine Abgrenzung, die leicht untergeht: Die Admin-Rolle in der App und das Konto im Portal sind zwei verschiedene Dinge. Wer die Instanz im Portal registriert hat, behält die Kontrolle über die Instanz selbst — anlegen, löschen, aktualisieren, Passwörter zurücksetzen — auch dann, wenn er in der App nur noch „user" ist. Die Übergabe der App-Admin-Rolle ändert daran nichts.
Soll auch das in ihrer Hand liegen, registriert sie die Instanz im Portal am besten von Anfang an selbst; nachträglich lässt sie sich auf Anfrage beim Betreiber übertragen. Dabei gilt, was für das Portal generell gilt: Es ist ein kostenloser Freundschaftsdienst, die Instanz läuft isoliert, aber auf trublues Server — ohne SLA, ohne Garantien und ohne eigene Datenkontrolle.
Beim Self-Hosting verschiebt sich die Grenze, aber sie verschwindet nicht: Dort betreibt jemand den Container, und das ist noch einmal etwas anderes als die Admin-Rolle im Tool. Wer den Server stellt, hat Zugriff auf die Datenbank, unabhängig davon, welche Rolle sein Konto trägt.
Welche Variante passt
Wenn deine Keyholderin führen soll, sich aber nicht mit Kontoverwaltung befassen möchte, ist Variante 1 die richtige. Sie ist schneller eingerichtet, hält die Verwaltung dort, wo sie ohnehin liegt, und ist gegenüber späteren Rollenwechseln unempfindlich.
Wenn die Übergabe vollständig sein soll — sie verwaltet, du trägst —, ist Variante 2 die richtige, inklusive der eigenen Rückstufung. Wer zusätzlich möchte, dass die Instanz selbst ihr gehört, lässt sie die Instanz von Anfang an registrieren.
Und wenn ihr am Ende beide Admin bleibt, ist auch nichts kaputt. Es fehlen dir dann die Posteingangs-Zeilen auf ihrer Seite, sonst nichts.
Die Klickpfade zum Nachschlagen stehen kompakt im Handbuch für In-App-Admins.