Rollen & Stationen

Drei Rollen

WERKSPUR kennt drei Rollen: operator, planner und admin, aufsteigend. Jede höhere Rolle kann alles, was die niedrigeren können, und darüber hinaus mehr.

Ein Bediener (operator) meldet sich an einer Station an und bucht dort. Er löst jede Aktion aus, deren min_role auf operator steht. Am Terminal scannt und bucht er und wählt bei Bedarf einen Status oder einen Grund-Code aus. Er legt weder Ansichten noch Aktionen an und sieht die Verwaltung dieser Artefakte nicht.

Ein Planer (planner) bringt zusätzlich die Werkzeuge mit, mit denen sich die Fertigung konfigurieren lässt. Er entwirft Ansichten am Bildschirm, prüft sie in der Vorschau und veröffentlicht sie erst dann für die Stationen. Aktionen selbst legt er nicht an; deren Bearbeitung bleibt dem Admin vorbehalten.

Ein Admin (admin) verwaltet zusätzlich Aktionen, Trigger, Zielsysteme und Secrets. Er legt außerdem gespeicherte Abfragen an, auf denen Ansichten und Aktionen aufbauen. Er weist einer Gruppe eine Ansicht zu; das Paar erscheint als Abteilung. Er prüft das Audit-Protokoll und kann damit gespeicherte Ereignisse nach Akteur, Typ, Zeitraum und Stream eingrenzen. Nur er hat Zugriff auf den Assistenten, der Ansichten, Abfragen und Aktionen aus einem Prompt vorschlägt. Die laufende Pflege von Zugängen und die Grenzen der Kettenprüfung beschreibt Benutzer & Audit.

Diese Rangfolge gilt einheitlich, für Ansichten, für Aktionen und für die Verwaltung selbst. Keine Rolle steht seitwärts einer anderen; ein Admin sieht und kann alles, was ein Planer sieht und kann, und ein Planer alles, was ein Bediener sieht und kann.

min_role an der Aktion

Ob jemand eine Aktion aufrufen darf, entscheidet nicht seine Rolle allein, sondern die Aktion selbst. Jede Aktion trägt ihr eigenes min_role: operator, planner oder admin. Das ist die einzige Zugriffsschranke der Aktion.

Ein Admin definiert die Aktion und legt dabei fest, wer sie auslösen darf. Bei min_role: operator kann jede Station die Aktion sehen und auslösen. Verändert sie ein externes System oder schließt sie einen Auftrag endgültig ab, kann der Admin min_role: planner oder min_role: admin setzen. Bediener sehen die Aktion dann nicht.

Diese Schranke sitzt an der Aktion, nicht am Kommando dahinter. Ein Kommando wie machine.set_state trägt zwar selbst eine Rollenangabe, doch die dient nur der Dokumentation; ob ein Bediener es aufrufen darf, entscheidet beim Aufruf ausschließlich das min_role der Aktion, die es einbettet. So kann derselbe Kommando-Schritt in einer für Bediener freigegebenen Aktion stecken und in einer anderen, nur für Admins gedachten Aktion, ohne dass sich am Kommando selbst etwas ändert.

Das Kapitel Aktionen beschreibt min_role und die übrige Anatomie einer Aktion im Detail.

Registrierte Stationen

Bei einem nicht leeren Stationsnamen prüft der Server den Eintrag gegen das Stationsregister. Meldet sich ein Bediener oder Planer mit einem unbekannten Namen an, lehnt das System die Anmeldung auch mit gültigem Badge und gültiger PIN ab. Ein abgelehnter Stationsname erzeugt keine Sitzung.

Eine Station bleibt bewusst simpel: ein Name und ein Anzeigename, sonst nichts. Der Name identifiziert das Terminal beim Login, der Anzeigename erscheint in der Oberfläche, etwa auf der Maschinenwand oder im Verlauf einer Buchung. Soll ein Bediener oder Planer einen nicht leeren Stationsnamen verwenden, legt ein Admin die Station vor dem ersten Login an. Wie ein Admin eine Station anlegt und pflegt, zeigt das Kapitel Stationen.

Das Feld „Station“ darf leer bleiben. Ein leerer Wert wird für jede Rolle akzeptiert. Admins umgehen die Registerprüfung auch bei einem nicht leeren Namen, weil sie das Stationsregister selbst verwalten dürfen. Die Anwendung speichert den eingegebenen Wert mit der Sitzung und übernimmt ihn in spätere Audit-Metadaten. Eine Station ist deshalb nur dann ein verlässlicher Ortsnachweis, wenn Bediener und Planer einen registrierten Namen verwenden. Wie eine Station die Anmeldung und den ersten Scan begleitet, zeigt das Kapitel Der Shopfloor-Prozess.

Die Rollenhierarchie und die Stationsprüfung wirken gemeinsam am Login. Ein nicht leerer Stationsname bildet für Bediener und Planer eine Grenze; Admins dürfen diese Registerprüfung umgehen.

flowchart TD
    Operator["Bediener"] -->|"Rechte enthalten in"| Planner["Planer"]
    Planner -->|"Rechte enthalten in"| Admin["Admin"]

    Login["Anmeldung"] --> Named{"Stationsname angegeben?"}
    Named -->|"Nein"| Session["Sitzung"]
    Named -->|"Ja"| IsAdmin{"Rolle Admin?"}
    IsAdmin -->|"Ja"| Session
    IsAdmin -->|"Nein"| Registered{"Station registriert?"}
    Registry["Stationsregister"] --> Registered
    Registered -->|"Ja"| Session
    Registered -->|"Nein"| Reject["Anmeldung abgelehnt"]

Keine Standard-Zugänge

WERKSPUR liefert keinen vorinstallierten Admin-Zugang aus. Bei jedem Serverstart ruft WERKSPUR die Bootstrap-Erstellung auf, wenn die Umgebungsvariablen für Badge und PIN beide konfiguriert sind. Ist die Benutzertabelle zu diesem Zeitpunkt noch leer, entsteht daraus der erste Admin. Sind die Variablen anfangs nicht gesetzt, können Sie sie später gemeinsam setzen und den Server neu starten; solange die Benutzertabelle leer geblieben ist, legt dieser Start den Admin an.

Sobald irgendein Benutzer existiert, bleibt die Bootstrap-Erstellung bei jedem weiteren Start ohne Wirkung und legt keinen zusätzlichen Admin an. Ein direkter Datenbankeingriff ist deshalb nicht nötig, solange die Benutzertabelle leer ist und sich der Zugang durch nachträgliches Setzen beider Variablen und einen Neustart wiederherstellen lässt. Die Betriebsseite dieser Regel und die passenden Umgebungsvariablen beschreibt Sicherheit im Betrieb.

Einen Bootstrap-PIN mit lauter gleichen Ziffern lehnt das System ab; ein solcher PIN ist zu leicht zu erraten, um als Zugangsschutz zu taugen.

Zwei weitere Sperren schützen die Admin-Rolle vor versehentlichem Verlust. Den letzten aktiven Admin kann niemand deaktivieren, auch ein anderer Admin nicht. Und niemand kann sich selbst deaktivieren. Beide Sperren verhindern, dass ein System versehentlich ganz ohne handlungsfähigen Admin dasteht.

Wie Sie Benutzer anlegen, PINs zurücksetzen sowie Konten deaktivieren und reaktivieren, zeigt Benutzer & Audit. Die Rolle wählen Sie beim Anlegen. Für bestehende Benutzer gibt es derzeit keine Funktion zum Rollenwechsel.

Beispiel

{
  "name": "status-melden",
  "summary": "Status melden",
  "min_role": "operator",
  "params": [
    {
      "name": "machine",
      "kind": "text",
      "label": "Maschine",
      "source": "context",
      "required": true
    },
    {
      "name": "state",
      "kind": "select",
      "label": "Status",
      "source": "operator",
      "required": true,
      "options": [
        "running",
        "idle",
        "down",
        "maintenance"
      ]
    },
    {
      "name": "reason",
      "kind": "select",
      "label": "Grund",
      "source": "operator",
      "required": false,
      "options_source": "machine-reasons"
    }
  ],
  "steps": [
    {
      "command": "machine.set_state",
      "bind": {
        "machine": {
          "param": "machine"
        },
        "reason": {
          "param": "reason"
        },
        "state": {
          "param": "state"
        }
      }
    }
  ]
}