97 lines
4.6 KiB
Markdown
97 lines
4.6 KiB
Markdown
## Der Ablauf für ein neues Team
|
|
|
|
1. **Workspace wählen oder anlegen.** Nach der Anmeldung landest du unter
|
|
*Workspaces*. Ein Workspace ist gedacht für eine Abteilung. Beim ersten
|
|
Start gibt es bereits den Workspace „Intern“.
|
|
2. **Projekt anlegen** unter *Projekte → Verwalten…*: Name, Bezeichner (erscheint
|
|
in Adressen und in der MCP-Konfiguration) und optional eine Beschreibung.
|
|
3. **Ersten Key anlegen:** Im neuen Projekt unter *Zugänge* einen Key mit der
|
|
Rolle `admin` für die verantwortliche Person erzeugen und ihr sicher
|
|
übergeben.
|
|
4. **Ab da verwaltet das Team sich selbst:** Die verantwortliche Person legt
|
|
weitere Keys für ihr Team und ihre Agenten an. Der Verweis auf diese Hilfe
|
|
(`{{SERVER}}/hilfe`) reicht als Einstieg.
|
|
|
|
Soll eine Abteilung ihre Projekte selbst anlegen, reicht es, ihr einen
|
|
[Workspace-Admin](#workspace-admins) einzurichten. Die Schritte 2 und 3
|
|
übernimmt dann sie.
|
|
|
|
## Workspaces
|
|
|
|
| Aktion | Wo |
|
|
|---|---|
|
|
| Anlegen, wählen | *Workspaces* in der Seitenleiste oder Klick auf den Namen oben in der Kopfleiste |
|
|
| Umbenennen, löschen | *Workspaces* → *Bearbeiten* |
|
|
|
|
Der Name des gerade gewählten Workspace steht immer oben in der Kopfleiste.
|
|
Alles, was du unter *Projekte* und *Protokoll (alle)* siehst, bezieht sich nur
|
|
auf diesen Workspace.
|
|
|
|
**Löschen** entfernt die Datenbankdatei des Workspace mit allen Projekten,
|
|
Einträgen und Keys. Zur Bestätigung muss der Name eingetippt werden. Rückgängig
|
|
machen lässt sich das nur aus einer Sicherung.
|
|
|
|
## Workspace-Admins
|
|
|
|
Ein Workspace-Admin legt im eigenen Workspace Projekte an, bearbeitet und
|
|
löscht sie und verwaltet deren Zugänge, nur über die Weboberfläche. Was er
|
|
genau darf und was nicht, steht unter
|
|
[Zugänge und Sicherheit](/hilfe/zugaenge#workspace-admin).
|
|
|
|
**Anlegen:** *Workspaces* → *Bearbeiten* → Abschnitt *Workspace-Admins*. Den
|
|
Namen der Person eintragen. Das Token (beginnt mit `wa_`) wird genau einmal
|
|
angezeigt und muss der Person sicher übergeben werden. Mit ihm meldet sie sich
|
|
an derselben Stelle an wie mit einem Key.
|
|
|
|
**Zurückziehen:** am selben Ort. Das Token gilt sofort nicht mehr, auch eine
|
|
laufende Sitzung endet. Beim Löschen des Workspace verschwinden seine
|
|
Workspace-Admins mit.
|
|
|
|
**Ungenutzte Zugänge:** Wie bei den Keys trägt ein aktiver Workspace-Admin,
|
|
der seit über 90 Tagen nicht benutzt wurde, die Marke *ungenutzt*. Die
|
|
Übersicht unter *Workspaces* zeigt je Workspace, wie viele Workspace-Admins
|
|
aktiv sind und wie viele davon ungenutzt. Ein Klick auf die Marke führt zur
|
|
Bearbeitungsseite. Ein vergessenes Token öffnet den ganzen Workspace, deshalb
|
|
im Zweifel zurückziehen.
|
|
|
|
Anlegen und Zurückziehen erscheinen im *Protokoll (alle)* des betroffenen
|
|
Workspace, ebenso jede Anmeldung eines Workspace-Admins.
|
|
|
|
## Projekte
|
|
|
|
Unter *Projekte → Verwalten…* stehen alle Projekte des Workspace mit
|
|
Eintragszahl und dem Stand ihres Schreibbudgets. Über *Bearbeiten* lassen sich
|
|
Name, Beschreibung und die **eigene Obergrenze fürs Schreibbudget** ändern.
|
|
Dort liegt auch das Löschen.
|
|
|
|
Das Schreibbudget kann nur der Plattform-Admin ändern, auch ein
|
|
Workspace-Admin nicht. Sonst könnte ein Team die Grenze selbst aufheben, die
|
|
gerade vor durchdrehenden Agenten schützen soll.
|
|
|
|
## Protokoll über alle Projekte
|
|
|
|
*Protokoll (alle)* zeigt die Vorgänge aller Projekte des gewählten Workspace,
|
|
auch das Anlegen und Löschen von Projekten.
|
|
|
|
## Sicherung und Export
|
|
|
|
Die eigentliche Sicherung läuft außerhalb der Oberfläche über
|
|
`scripts/backup.sh`. Das Skript sichert jede Workspace-Datei einzeln, sodass
|
|
sich auch eine einzelne Abteilung wiederherstellen lässt.
|
|
|
|
Ist auf dem Server ein Exportverzeichnis eingerichtet, schreibt Munin einmal
|
|
täglich alle Einträge aller Workspaces als Markdown-Dateien dorthin, als
|
|
zusätzliche, lesbare Sicherung, etwa für ein Git-Repository. Unter *Projekte*
|
|
exportiert der Knopf **Jetzt exportieren** sofort den gerade gewählten
|
|
Workspace, zum Beispiel vor einer größeren Änderung.
|
|
|
|
Ohne Exportverzeichnis und ohne Zugriff auf den Server geht es über den
|
|
Download: **Alle als ZIP herunterladen** unter *Projekte* liefert alle
|
|
Projekte des gewählten Workspace in einem Archiv, *Als ZIP herunterladen* über
|
|
der Eintragsliste ein einzelnes Projekt. Beides dürfen auch Workspace-Admins. Jeder
|
|
Download steht im Protokoll.
|
|
|
|
Zurück kommt ein Export über den [Import](/hilfe/weboberflaeche#import) im
|
|
jeweiligen Projekt: das ZIP eines Projekts direkt hochladen, oder den
|
|
Projektordner aus dem Exportverzeichnis als ZIP-Archiv packen und hochladen. So lässt sich auch ein einzelnes Projekt wiederherstellen, ohne
|
|
die ganze Workspace-Datei zurückzuspielen.
|