Menue-Anpassen

Aus GTDS
Zur Navigation springen Zur Suche springen

Prinzip

GTDS regelt den Zugriff auf Masken und damit den Aufbau des Menübaums über Einträge in die Tabelle GTDS_PARAMETER, nach dem Schema "SERVLET.<maske>.ERLAUBT. Zulässige Werte sind "Ja" und "Nein". Wird bei der Bestimmung des Parameterwerts kein Wert gefunden, wird als Ergebnis "Ja" angenommen.

  • Dabei haben Parameter für Masken, die als Servlets realisiert sind, den Servletnamen in Großbuchstaben an der Stelle von "<maske>" stehen.
  • Bei Masken, die über das REST-API umgesetzt sind, erfolgt der Eintrag für <maske> nach dem Schema ../REST/XXXXX.HTML

Das, was in der Adressleiste hinter ; oder ? steht, wird nicht gewertet.

Beispiele:

URL in der Adressleiste (nach dem Server:Port) GTDS-Parameter
/gtds/servlet/haemonkausw SERVLET.HAEMONKAUSW.ERLAUBT
/gtds/rest/lssErfassung.html SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT

Damit lässt sich feingranuliert und benutzerbezogen festlegen, wie der Menübaum für einen Benutzer aussieht. Zur Feststellung, ob ein Benutzer eine bestimmte Maske aufrufen darf, wird seit August 2025 die Funktion param.servlet_erlaubt verwendet.

Funktion param.servlet_erlaubt

Parameter Wert Beschreibung
welches Maskenname Es wird hier nur der Servletname bzw. der REST-API-Name übergeben, also das, was oben unter <maske> beschrieben ist,

Beispiel:

  • HAEMONKAUSW entsprechend dem Parameter SERVLET.HAEMONKAUSW.ERLAUBT
  • ../REST/LSSERFASSUNG.HTML entsprechend dem Parameter SERVLET.../REST/LSSERFASSUNG.HTML.ERLAUBT
ben_id Name eines Profilnutzers Ein Profilnutzer ist eine echte Benutzerkennung oder ein fiktiver Name für ein Profil, also z.B. "TUMORKONFERENZ", "NORMALBENUTZER" "STAMMDATEN".
abt_id Abteilung_ID Wäre sinnvoll, wenn die Berechtigung von der Vorgabeabteilung eines Benutzers abhängig ist, vermutlich eher unrealistisch
mand_id Mandant.ID Wäre sinnvoll, wenn die Berechtigung vom Vorgabemandanten eines Benutzers abhängig ist, vermutlich eher unrealistisch

Die Funktion arbeitet nach dem Prinzip der Spezifität/Priorität. Sie durchläuft alle Einträge für den gewünschten Parameter. Sobald einer auf die übergebenen Parameter ben_id/abt_id/mand_id passt, wird der Wert zurückgegeben. Höchste Priorität haben die Einträge für den aktuellen Datenbankbenutzer, niedrigste nicht spezifisch vergebene Einträge.

Priorität:

  1. Übereinstimmung in USER (DB-Benutzer)
  2. Übereinstimmung in ben_id
  3. Übereinstimmung in abt_id
  4. Übereinstimmung in mand_id
  5. Parameter ist nicht einschränkend gesetzt (globaler Parameter)
  6. Parametereintrag existiert nicht

Bemerkungen:

  • Der Menübaum wird einmalig bei Anmeldung aus dem Vorgabekontext bestimmt, Änderungen des Kontexts werden nicht berücksichtigt.
  • USER wird nicht übergeben, sondern ergibt sich aus der Datenbankverbindung.
  • ben_id wird aus dem GTDS-Parameter WEBGTDS.MENUE_BENUTZER bestimmt.
  • abt_id wird aus der Kontext-Abteilung bestimmt.
  • mand_id wird aus dem Kontext-Mandanten bestimmt.
  • Wenn zwar der passende Parametereintrag auf einer beliebigen Ebene existiert, aber keinen Wert hat, wird ersatzweise "Ja" angenommen. Parametereinträge auf der Ebene ben_id müssen aber immer einen Wert eingetragen haben.
  • Wenn kein passender Parametereintrag vorhanden ist, wird ebenfalls ersatzweise "Ja" angenommen.
  • Da der Menübaum nur einmalig festgelegt wird, könnte man argumentieren, dass man überhaupt keine Parameter übergeben müsste. Da die Funktion aber für alle potentiellen Masken aufgerufen wird, werden die Parameter einmalig vorab bestimmt.

Anwendungshinweise

Die neu eingeführte Funktionalität eines Profilbenutzers ermöglicht eine einfachere Pflege über weniger Parametereinträge. So könnte "TUMORKONFERENZ" nur Masken zur Verfügung stellen, die zur Anmeldung und Durchführung einer Tumorkonferenz dienen, "NORMALBENUTZER" vielleicht nur die Dokumentationsmasken im engeren Sinn zur Verfügung stellen und "STAMMDATEN" zusätzlich den Zugriff auf die Stammdaten ermöglich. Zu beachten ist, dass es derzeit nicht vorgesehen ist, einem Benutzer mehrere Profile zuzuweisen.

Wie man vorgeht, wenn man ein Profil anlegen will, hängt davon ab, ob man eher Profile anlegen will, in denen man nur wenig verbieten oder viel verbieten will. Dementsprechend kann man die globalen Parameter eher auf Ja setzen und dann nur die Unerwünschten profilbezogen verbieten oder umgekehrt.

Die Einträge in der Tabelle MENUE_EINTRAG umfassen alle Masken. Die IDs sind dort thematisch gruppiert, z.B. sind (derzeit) zwischen 400 und 499 die Einträge für das Leitstellenmenü zu finden. So kann man skriptbasiert ganze Bereiche frei- oder abschalten. Beispiele findet man im Skript "init_menu_parameter.sql" im GTDS-Verzeichnis. Dieses Skript wird derzeit beim Durchführen eines Update oder Patches ausgeführt und sorgt dafür, dass der Bereich "Verwaltung" und einige registerspezische Masken nur für den Durchführenden des Updates (also OPS$TUMSYS) freigeschaltet sind, global aber auf "Nein" gesetzt werden.