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
- Im Kundenbereich den richtigen Workspace wählen und „Spielanbindung“ unter
/workspace/game-api/öffnen. - Technischen Jobnamen des Frameworks ermitteln. Nicht die sichtbare Jobbezeichnung oder den Namen eines Police-Scripts verwenden.
- Jobname, numerischen Grade, Behördenkennung und Rangkennung eintragen. Die Kennungen müssen zu den tatsächlich angelegten Einträgen gehören.
- Mapping speichern und für jeden freizugebenden Grade wiederholen.
- 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-Job | Grade | Behördenkennung | Rangkennung |
|---|---|---|---|
police_test | 0 | polizei-test | anwaerter-test |
police_test | 1 | polizei-test | beamter-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
- Fiktiven Mitarbeiter im Test-MDT mit aktiver Behördenmitgliedschaft anlegen.
- Im eigenen Profil „Spielfigur verknüpfen“ öffnen und Einmalcode erzeugen.
- Im Spiel
/mdtlink CODEausführen, sofern das installierte Bridge-Paket den Befehl unterstützt. - 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/jobsnutzen 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.
Unklare Stellen oder fehlende Schritte meldest du im LexoNET-Discord oder als Ticket im Kundenbereich.