Anleitung für In-App-Admins

Was die Admin-Rolle ist — und was nicht

Als In-App-Admin verwaltest du Benutzerkonten und Rollen innerhalb einer Tracker-Instanz. Das ist eine Anwendungs-Rolle, kein Server-Zugang.

Nutzt du das Portal, läuft deine Instanz auf fremdem Server als kostenloser Freundschaftsdienst — ohne SLA, ohne Garantien. Admin im Tool zu sein bedeutet also nicht, die Daten technisch selbst zu kontrollieren. Wer echte Datenhoheit will, betreibt den Container auf eigener Infrastruktur (siehe Self-Hosting).

Benutzerverwaltung

In der Benutzerverwaltung legst du Accounts an, bearbeitest und löschst sie, vergibst Rollen und setzt bei Bedarf Passwörter zurück. Für Tests kannst du Demo-User erstellen.

Die Benutzerverwaltung ist bewusst von der Keyholder-Übersicht getrennt: Kontroll-Direktiven und Account-Verwaltung sind zwei unterschiedliche Aufgaben und liegen in getrennten Bereichen.

Eine Keyholderin aufnehmen

Eine Einladung per E-Mail gibt es nicht — das Konto legst du von Hand an, im Portal unter Dashboard → deine Instanz → Tracker-Benutzer oder in der Instanz unter Benutzer → Neuer Benutzer. Die Zugangsdaten gibst du ihr weiter, das Passwort ändert sie danach selbst.

Soll sie die Instanz verwalten, setze ihre Rolle auf „admin“ (Benutzer → die Person → Einstellungen → Rolle) und stufe dich danach selbst auf „user“ zurück; der letzte verbleibende Admin kann das nicht. Führen kann sie dich auch ohne deine Rückstufung — für einen Träger mit Admin-Rolle entfallen aber die Zeilen im Keyholder-Posteingang, Mail und Push laufen unverändert.

Keyholderin ohne Benutzerverwaltung

Soll sie dich führen, aber keine Konten verwalten, gib ihr die Rolle „user“ und weise sie unter Benutzer → dein Konto → Einstellungen → Keyholder als Keyholderin zu. Sie hat damit alle Keyholder-Befugnisse über dein Konto, aber keinen Zugriff auf die Instanz-Verwaltung.

Zuweisen kann das nur ein Admin, also du selbst, solange du es noch bist. Die Zuweisung hängt an keiner Rolle und gilt deshalb auch dann, wenn du Admin bleibst.

Globaler und beschränkter Admin

Standardmässig sieht ein globaler Admin alle Benutzer der Instanz. Ist die Instanz auf zugewiesene Beziehungen beschränkt (Konfigurations-Flag `USE_ADMIN_RELATIONSHIPS`), sieht ein Admin nur die ihm zugeordneten User; Admins bleiben dabei immer in der Liste, auch ohne Zuweisung.

So lässt sich eine Instanz mit mehreren Admins sauber aufteilen, statt jedem Admin Einblick in alle Konten zu geben.

Admins in der Keyholder-Liste

Öffnest du bei einem Sub die Keyholder-Verwaltung, steht jeder Admin dort bereits als impliziter, nur-lesender Eintrag — er sieht dessen Daten ohnehin über seine Rolle und nicht über eine Zuweisung.

Deshalb lässt sich ein Admin nicht zusätzlich als Keyholder zuweisen. Wer jemanden ausdrücklich als Keyholderin führen will, legt dessen Konto mit der Rolle „user“ an. Die Liste gehört zur Benutzerverwaltung und ist damit nur für Admins sichtbar. Der Sub erfährt davon nichts: der Tracker nennt ihm nirgends, wer Einblick in seine Daten hat — wenn er es wissen soll, sag es ihm.

Rollenbewusstes Portal

Der Portal-Titel passt sich deiner Rolle an: Handelst du als Keyholder, siehst du das "Keyholder-Portal"; in der Verwaltungsansicht das "Admin-Portal".

So ist jederzeit erkennbar, in welchem Kontext du gerade arbeitest, und die beiden Aufgabenbereiche vermischen sich nicht in der Oberfläche.

Benachrichtigungen pro User

Als Admin verwaltest du die Benachrichtigungseinstellungen einzelner User. Damit kannst du etwa für einen bestimmten Account bestimmte Event-Typen aktivieren oder abschalten.

Das ergänzt die Selbstverwaltung des Subs und ist nützlich, wenn zentrale Vorgaben für Benachrichtigungen gewünscht sind.

Pflichtgerät erzwingen

Über die Admin-Rolle lässt sich ein Pflichtgerät nicht nur als Vorgabe setzen, sondern durchsetzen: Wird ein falsches Gerät getragen und erkannt, markiert das System dies automatisch.

Das geht über die reine Keyholder-Vorgabe hinaus, bei der das Gerät nur als Anforderung genannt, aber nicht systemseitig erzwungen wird.

Foto-Prüfung einrichten

Die automatische Foto-Prüfung liest den Kontroll-Code im Foto, prüft die Siegelnummer und erkennt das Gerät. Voreingestellt ist sie aus. Eingeschaltet wird sie unter „Einstellungen“ → „Foto-Prüfung“; den Abschnitt sieht nur ein Admin, weil die Einstellung für die ganze Instanz gilt.

Am einfachsten geht es mit Anthropic, darauf ist die Prüfung abgestimmt. Auf platform.claude.com legst du ein Konto an, lädst Guthaben auf und erzeugst unter „API Keys“ einen Schlüssel; er wird nur einmal angezeigt. In der App wählst du „Anthropic (Claude)“, fügst den Schlüssel ins Feld „API-Schlüssel“ ein und lässt die beiden Modellfelder leer, dann gelten die Vorgaben.

Vor dem Speichern tippst du auf „Einstellung testen“. Die App prüft die Einstellung an einem Beispielfoto: Sie muss den richtigen Code erkennen und eine falsche Zahl zurückweisen. Meldet sie, der Anbieter habe den Schlüssel abgelehnt, ist er falsch kopiert oder das Konto hat kein Guthaben. Danach speicherst du.

Die Kosten laufen über dein eigenes Konto beim Anbieter. Die Fotos gehen zur Prüfung dorthin, und die Subs sehen das am ⓘ neben dem Foto-Feld. Statt Anthropic stehen OpenAI, Google Gemini, Mistral, ein anderer OpenAI-kompatibler Dienst oder ein eigener Server mit Ollama zur Wahl. Andere Modelle lesen Handschrift womöglich schlechter, deshalb dort erst recht vorher testen.

Portal-Instanzen, die schon vor Tracker 6.2.5 bestanden, prüften über den Schlüssel des Portal-Betreibers. Dieser Übergang gilt nach dem Update der Instanz noch 30 Tage; solange er läuft, steht das Enddatum im Abschnitt „Foto-Prüfung“. Danach ist die Prüfung aus, bis ein eigener Schlüssel hinterlegt ist. Ohne Prüfung funktionieren Kontrollen weiter, die Keyholderin beurteilt das Foto dann von Auge.

Betrieb und Konfiguration

Themen wie Feature-Flags und globale Spracheinstellungen berühren den Betrieb der Instanz. Sie werden hier nur kurz angerissen, weil sie über die reine Anwendungs-Administration hinausgehen.

Für Installation, Konfiguration und den tatsächlichen Serverbetrieb ist die bestehende Self-Hosting-Seite die massgebliche Quelle. Bitte ziehe für alle Betriebsthemen diese Dokumentation heran.