Bemerkungen zur Frage der Oberflächenberechtigungen
Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
8 Antworten auf „Bemerkungen zur Frage der Oberflächenberechtigungen“
Gut, das habe ich soweit alles verstanden und finde das Konzept persönlich gut und unterstütze es. Meine Bitte daher wäre, ob Sie mir dieses Konzept dann in einer kurzen Übersicht als Dokument zur Verfügung stellen könnten, da mit den NERZ-Mitgliedern vereinbart ist, dass ich es dort kurz abstimme, bevor es umgesetzt wird. In dem Dokument darf gerne der Hinweis enthalten sein, dass ihr (unser) Konzept im Prinzip dem vom Inovat entspricht, aber Verbesserungen/Vorteile (Singleton, csv-Datei) enthält. Ich denke, dann sollte es kein Problem sein, das Konzept durchzubringen.
Die Mitglieder der Fach-Telefonkonferenz haben dem Konzept zugestimmt. Es kann somit für die weitere Überarbeitung zugrunde gelegt und umgesetzt werden.
Zusatz: die TBuV-105, laut der parametriert werden kann, ob Funktionen, für die keine Berechtigung vorliegt ausgegraut oder ausgeblendet werden (falls es Menüeinträge oder Schaltflächen sind) wurde bis her (soweit mir bekannt) nicht umgesetzt und sollte gestrichen oder in das Berechtigungskonzept mit einbezogen werden, wobei ich für die erstere Variant plädiere, da Oberflächenberechtigungen gemäß gegenwärtiger Benutzung eigentlich abstrakter betrachtet werden müssen.
Dass das Konzept nicht wirklich erneuert, sondern nur vereinfachend angepasst wird, ist selbstredend in Ordnung.
Inwieweit deckt sich Ihr Vorschlag mit dem von Inovat bereits in dessen Projekten realisierten Konzept der Oberflächenberechtigungen? Haben Sie mit Herrn Kniß schon darüber gesprochen?
Natürlich wurde die Möglichkeit, Oberflächenberechtigungen an Systemobjekte oder UI-Element zu koppeln, noch nie genutzt – aber doch hauptsächlich weil alle an der seitherigen Umsetzung verzweifelt/gescheitert sind? Deswegen muss das ja noch nicht heißen, dass die Möglichkeit an sich nicht doch irgendwo benötigt werden könnte.
Aber habe ich Sie richtig verstanden, dass diese Möglichkeit auch mit Ihrem Vorschlag möglich ist, bloß muss sich eben der Plug-in-Realisierer darum kümmern und die Freigabe/Sperrung entsprechend auswerten?
Wenn Ihr Vorschlag eine starke Vereinfachung darstellt, ist das für mich zunächst einmal kein Problem. Wichtig ist mir zunächst, dass auf jeden Fall eine Lösung entsteht, die auch tatsächlich einsetzbar ist (ohne minutenlange Wartezeiten). Ich könnte mir auch ggfs. den Weg vorstellen, zunächst diesen Vorschlag umzusetzen und eine größere Komplexität zu einem späteren Zeitpunkt nachzurüsten, wenn der Bedarf tatsächlich besteht.
Das früher genannte Kompatibilitäts-Plug-in darf durchaus zum Einsatz kommen. Dessen Funktion habe ich jetzt verstanden und befürworte es.
Laut technischen Anforderungen TBuV-103-105 werden die Oberflächenberechtigungen durch:
Wer? (wäre jetzt eine oder mehrere Benutzerklassen)
Was? (Wäre jetzt eine über eine ID definierte Funktion)
Wie? (Wäre jetzt Sperrung oder Freigabe)
Worauf? (würde entfallen)
Ausnahmen? (würde entfallen)
definiert.
Das Worauf wäre hier die Definition von Dialogen und UI-Elementen, die nach gegenwärtigem Stand ohnehin nicht identifizierbar sind, oder gibt es ein Plugin, bei dem Sie per ID einen bestimmten Button, eine Liste oder sonst irgendein Element benennen könnten, um es per Recht einzuschränken. Selbst wenn, müsste das vom Plugin unterstützt werden, was aber dann genau so gut mit einer neuen Oberflächenfunktion möglich wäre, die sich auf genau dieses Element bezieht.
Mit Herrn Kniß habe ich bezüglih Rahmenwerk noch nicht gesprochen, ich kenne aber die INOVAT-Rechte-Bibliothek, die im Wesentlichen ein Singleton(!) zur Verfügung stellt, das die Funktionen:
– hat der aktuelle Nutzer die Freigabe für die Funktion mit der ID xxx und (auf Umwegen)
– hat die Benutzerklasse kkk die Freigabe für die Funktion mit der ID xxx.
Das INOVAT-Plugin zur Konfiguration der Rechte, das den vorhandenen Parameterdatensatz, der auch von der Original-Berchtigungsverwaltung verwendet wird, beschreibt, zeigt eine Matrix, in der die Spalten die Berechtigungsklassen und die Zeilen die Oberflächenfunktionen kennzeichnen, die Zellen der Matrix bestimmen Freigabe oder Sperrung. Das entspricht also genau der dargestellten Vereinfachung. Nachteilig finde ich persönlich das das Plug-In zur Parametrierung der Rechte aus der INOVAT-Bibliothek auf eine oder mehrere CSV-Konfigurationsdateien zurückgreift, die in einem Projektdatenverzeichnis hinterlegt wird.
Noch eine Bemerkung zum Kompatibilitäts-Plug-In, damit hier kein Mißverständnis entsteht:
Das Plug-In stellt lediglich sicher, das bestehende Software kompilierbar und im Wesentlichen funktionsfähig ist, d.h. bespielsweise kann mit den „kompatiblen“ Funktionen eine Abfrage auch mit ID’s von Elementen erfolgen. Diese zusätzlichen Parameter werden praktisch aber ignoriert und es erfolgen entsprechende Warnmeldungen. Der volle Funktionsumfang im ursprünglichen Sinne wird nicht unterstützt, wobei in der Regel davon ausgegangen wird, dass die Funktionalität ohnehin nicht in der vorliegenden Weise genutzt wurde. Das Problem rührt daher, das in der vorliegenden Rahmenwerk-Implementierung nicht klar ist, was wirklich öffentliche API ist und was aus internen Strukturgründen „public“ ist, aber eigentlich nicht „öffentlich“ sein sollte. Leider wurden in den Plug-Ins auch immer alle Pakete exportiert.
Das Plug-In soll also in erster Linie eine Hilfe bei der schrittweisen Anpassung sein. Es versucht, möglichst die volle verwendete Funktionalität auch ohne Anpassung der ursprünglichen Plug-Ins zu gewährleisten, kann das aber wahrscheinlich nicht zu 100 Prozent erfüllen.
Gut, das habe ich soweit alles verstanden und finde das Konzept persönlich gut und unterstütze es. Meine Bitte daher wäre, ob Sie mir dieses Konzept dann in einer kurzen Übersicht als Dokument zur Verfügung stellen könnten, da mit den NERZ-Mitgliedern vereinbart ist, dass ich es dort kurz abstimme, bevor es umgesetzt wird. In dem Dokument darf gerne der Hinweis enthalten sein, dass ihr (unser) Konzept im Prinzip dem vom Inovat entspricht, aber Verbesserungen/Vorteile (Singleton, csv-Datei) enthält. Ich denke, dann sollte es kein Problem sein, das Konzept durchzubringen.
Ich habe einen kurze Beschreibung der Berechtigungsverwaltung hinterlegt, als Docx-File und als PDF
Danke. Ich werde das Konzept mit den NERZ-Mitgliedern abstimmen und Sie über das Ergebnis informieren.
Die Mitglieder der Fach-Telefonkonferenz haben dem Konzept zugestimmt. Es kann somit für die weitere Überarbeitung zugrunde gelegt und umgesetzt werden.
Was ich noch vergessen habe: inwieweit deckt sich Ihr Vorschlag denn noch mit den ursprünglichen Anforderungen an diese Funktionalität?
Siehe Anmerkungen hier.
Zusatz: die TBuV-105, laut der parametriert werden kann, ob Funktionen, für die keine Berechtigung vorliegt ausgegraut oder ausgeblendet werden (falls es Menüeinträge oder Schaltflächen sind) wurde bis her (soweit mir bekannt) nicht umgesetzt und sollte gestrichen oder in das Berechtigungskonzept mit einbezogen werden, wobei ich für die erstere Variant plädiere, da Oberflächenberechtigungen gemäß gegenwärtiger Benutzung eigentlich abstrakter betrachtet werden müssen.
Dass das Konzept nicht wirklich erneuert, sondern nur vereinfachend angepasst wird, ist selbstredend in Ordnung.
Inwieweit deckt sich Ihr Vorschlag mit dem von Inovat bereits in dessen Projekten realisierten Konzept der Oberflächenberechtigungen? Haben Sie mit Herrn Kniß schon darüber gesprochen?
Natürlich wurde die Möglichkeit, Oberflächenberechtigungen an Systemobjekte oder UI-Element zu koppeln, noch nie genutzt – aber doch hauptsächlich weil alle an der seitherigen Umsetzung verzweifelt/gescheitert sind? Deswegen muss das ja noch nicht heißen, dass die Möglichkeit an sich nicht doch irgendwo benötigt werden könnte.
Aber habe ich Sie richtig verstanden, dass diese Möglichkeit auch mit Ihrem Vorschlag möglich ist, bloß muss sich eben der Plug-in-Realisierer darum kümmern und die Freigabe/Sperrung entsprechend auswerten?
Wenn Ihr Vorschlag eine starke Vereinfachung darstellt, ist das für mich zunächst einmal kein Problem. Wichtig ist mir zunächst, dass auf jeden Fall eine Lösung entsteht, die auch tatsächlich einsetzbar ist (ohne minutenlange Wartezeiten). Ich könnte mir auch ggfs. den Weg vorstellen, zunächst diesen Vorschlag umzusetzen und eine größere Komplexität zu einem späteren Zeitpunkt nachzurüsten, wenn der Bedarf tatsächlich besteht.
Das früher genannte Kompatibilitäts-Plug-in darf durchaus zum Einsatz kommen. Dessen Funktion habe ich jetzt verstanden und befürworte es.
Laut technischen Anforderungen TBuV-103-105 werden die Oberflächenberechtigungen durch:
definiert.
Das Worauf wäre hier die Definition von Dialogen und UI-Elementen, die nach gegenwärtigem Stand ohnehin nicht identifizierbar sind, oder gibt es ein Plugin, bei dem Sie per ID einen bestimmten Button, eine Liste oder sonst irgendein Element benennen könnten, um es per Recht einzuschränken. Selbst wenn, müsste das vom Plugin unterstützt werden, was aber dann genau so gut mit einer neuen Oberflächenfunktion möglich wäre, die sich auf genau dieses Element bezieht.
Mit Herrn Kniß habe ich bezüglih Rahmenwerk noch nicht gesprochen, ich kenne aber die INOVAT-Rechte-Bibliothek, die im Wesentlichen ein Singleton(!) zur Verfügung stellt, das die Funktionen:
– hat der aktuelle Nutzer die Freigabe für die Funktion mit der ID xxx und (auf Umwegen)
– hat die Benutzerklasse kkk die Freigabe für die Funktion mit der ID xxx.
Das INOVAT-Plugin zur Konfiguration der Rechte, das den vorhandenen Parameterdatensatz, der auch von der Original-Berchtigungsverwaltung verwendet wird, beschreibt, zeigt eine Matrix, in der die Spalten die Berechtigungsklassen und die Zeilen die Oberflächenfunktionen kennzeichnen, die Zellen der Matrix bestimmen Freigabe oder Sperrung. Das entspricht also genau der dargestellten Vereinfachung. Nachteilig finde ich persönlich das das Plug-In zur Parametrierung der Rechte aus der INOVAT-Bibliothek auf eine oder mehrere CSV-Konfigurationsdateien zurückgreift, die in einem Projektdatenverzeichnis hinterlegt wird.
Noch eine Bemerkung zum Kompatibilitäts-Plug-In, damit hier kein Mißverständnis entsteht:
Das Plug-In stellt lediglich sicher, das bestehende Software kompilierbar und im Wesentlichen funktionsfähig ist, d.h. bespielsweise kann mit den „kompatiblen“ Funktionen eine Abfrage auch mit ID’s von Elementen erfolgen. Diese zusätzlichen Parameter werden praktisch aber ignoriert und es erfolgen entsprechende Warnmeldungen. Der volle Funktionsumfang im ursprünglichen Sinne wird nicht unterstützt, wobei in der Regel davon ausgegangen wird, dass die Funktionalität ohnehin nicht in der vorliegenden Weise genutzt wurde. Das Problem rührt daher, das in der vorliegenden Rahmenwerk-Implementierung nicht klar ist, was wirklich öffentliche API ist und was aus internen Strukturgründen „public“ ist, aber eigentlich nicht „öffentlich“ sein sollte. Leider wurden in den Plug-Ins auch immer alle Pakete exportiert.
Das Plug-In soll also in erster Linie eine Hilfe bei der schrittweisen Anpassung sein. Es versucht, möglichst die volle verwendete Funktionalität auch ohne Anpassung der ursprünglichen Plug-Ins zu gewährleisten, kann das aber wahrscheinlich nicht zu 100 Prozent erfüllen.