LexoNETDocs
Docs 0.6.0Anmelden
Architektur und API

Jobzuordnung, Identität und Dienst

Die Spielanbindung ordnet einen Framework-Job einer Behörde und einen Grade einem Rang zu. Diese Zuordnung ersetzt weder eine aktive Personalmitgliedschaft noch die Fachrechte des MDT.

#Job-Mapping einrichten

  1. Im Kundenbereich den richtigen Workspace wählen und „Spielanbindung“ unter /workspace/game-api/ öffnen.
  2. Technischen Jobnamen des Frameworks ermitteln. Nicht die sichtbare Jobbezeichnung oder den Namen eines Police-Scripts verwenden.
  3. Jobname, numerischen Grade, Behördenkennung und Rangkennung eintragen. Die Kennungen müssen zu den tatsächlich angelegten Einträgen gehören.
  4. Mapping speichern und für jeden freizugebenden Grade wiederholen.
  5. Mit einem fiktiven Charakter die Zuordnung prüfen. Ein fremder Job und ein nicht gemappter Grade dürfen keine Rechte erhalten.

Synthetischer Planungsdatensatz, kein automatisch importierbarer Vertrag:

Framework-JobGradeBehördenkennungRangkennung
police_test0polizei-testanwaerter-test
police_test1polizei-testbeamter-test

Der Plattform-Formularcode akzeptiert Grades von 0 bis 1000. Fachlich passende Rangkennungen müssen zusätzlich in der Zielkonfiguration geprüft werden. Die Plattform-Mappingfelder authority_key und rank_key nicht ungeprüft als Connector-Feld behoerde verwenden; dort ist ein Behörden-Slug gefordert.

#Mapping pflegen

Einzelne Grades können aus der Tabelle entfernt werden. Wenn kein Grade mehr zu einem Job gehört, entfernt die Implementierung auch das leere Job-Mapping. Nach Umbenennung oder Entfall eines Framework-Jobs die Zuordnung gezielt aktualisieren und die Negativtests wiederholen.

#Identität verknüpfen

  1. Fiktiven Mitarbeiter im Test-MDT mit aktiver Behördenmitgliedschaft anlegen.
  2. Im eigenen Profil „Spielfigur verknüpfen“ öffnen und Einmalcode erzeugen.
  3. Im Spiel /mdtlink CODE ausführen, sofern das installierte Bridge-Paket den Befehl unterstützt.
  4. Aktive Mitgliedschaften abfragen; keine Mitgliedschaften anderer Mandanten erwarten.

Der Code gilt zehn Minuten und einmal. Die API verwendet vorrangig die vollständige license:-Kennung. Charakterdaten im optionalen Anzeigeobjekt sind keine Berechtigungsquelle.

#Dienst und Schnelllogin prüfen

dienst/melden benötigt identifier, behoerde und aktion (an oder ab). Das MDT prüft Verknüpfung, Vertrag, Mitgliedschaft, dienst.melden, aktives Modul und Behördenrichtlinie. Ein erneutes an eröffnet keinen zweiten Dienst. Historische Ereignisse dürfen im dokumentierten Puffer mit ursprünglichem zeitpunkt nachgereicht werden.

sitzung/ticket prüft getrennt desktop.nutzen. Das Ticket gilt 60 Sekunden und einmal. Strenge IC-Zugangsrichtlinien verlangen zusätzlich Charakterzuordnung und frische Presence; ein Mapping allein erfüllt das nicht.

#Typische Fehler

  • Joblabel statt technischem Jobnamen: Framework-Konfiguration vergleichen.
  • Grade mit Rangtext verwechseln: numerischen Framework-Grade und technische Rangkennung getrennt eintragen.
  • Jobwechsel sofort als Rechteübernahme behandeln: MDT-Mitgliedschaft und Fachrechte unabhängig prüfen.
  • sync/jobs nutzen wollen: Dieser Connector-Endpunkt ist für v1.1 geplant.

#Wer darf das?

Im Plattform-Quellcode verwalten owner und admin die Spielanbindung. Serveradministration bestätigt die technischen Jobs; MDT-Systemleitung verwaltet Behörden, Mitgliedschaften und Rechte.