Bereitstellung des Oberflächenobjekts über das Rahmenwerk
Entschuldigung aber du hast nicht die Rechte um dieses Post zu sehen!
5 Antworten auf „Bereitstellung des Oberflächenobjekts über das Rahmenwerk“
Die Argumentation überzeugt.
Aber wie könnten dann solche Funktionserweiterungen aussehen? Was könnte denn zum Beispiel besagtes Plug-in „GTM für Rahmenwerk“ an Erweiterungen benötigen? Oder wäre dann die Aufgabenstellung eigentlich nur, den RW-GTM an das überarbeitete Oberflächenberechtigungskonzept anpassen zu müssen?
Das GTM-Plug-In sollte davon nicht betroffen sein. ich tippe eher auf das Rechte-Konfigurations-Plug-In aus der INOVAT-Bibliothek.
Dieses würde dann Funktionen benötigen wie:
– setze die Berechtigung für eine Funktion und eine Benutzerklasse
– speichere die aktuelle Einstellung der Berechtigungen
Die Funktionalität sollte aber eigentlich integraler Bestandteil des Rahmenwerks sein, also auch der Editor zum Bearbeiten der Rechte.
Ansonsten fallen mit momentan keine konkreten Anforderungen an die Funktionalität ein.
Ich würde Ihre Sicht der Dinge dann im NERZ-Änderungsmanagement eintragen.
Soll dann in dem Eintrag noch der Umfang der angesprochenen Funktionserweiterungen abgefragt werden? Oder ist Ihnen das eigentlich klar?
Ich sehe keine notwendigen Funktionserweiterungen, wenn das Rahmenwerk die Funktionalitäten:
– Oberflächenfunktionen anlegen/entfernen
– Berechtigung für Nutzer(Benutzerklassen) abfragen
– Anmelden auf Änderungen von Oberflächenfunktionen
– Berechtigungen über im Rahmenwerk vorhandenen Editor bearbeiten
zur Verfügung stellt.
Falls diese Funktionalität nicht reicht, wäre es schon interessant, wo noch Bedarf besteht.
Das Feature wäre relativ leicht zu implementieren, widerspricht aber eigentlich der Intention der Verwendung und Aktualisierung des Rahmenwerks.
Richtig ist, dass das Rahmenwerk den Parameter auswerten muss, um die Parameter beim korrekten Objekt zu ermitteln.
Die Information. Welches Objekt das Rahmenwerk letztendlich verwendet sollte aber nicht für andere Plug-Ins von Bedeutung sein, da die Oberflächenberechtigungs-Verwaltung ja zentraler Bestandteil des Rahmenwerks selbst ist.
Der einzige Zweck, dieses Objekt zu kennen, wäre eine Umgehung der Verwaltung des Rahmenwerks, was aber doch eigentlich kontraproduktiv im Sinne der ERZ ist und zu einer UERZ führt (Uneinheitliche Rechnerzentralensoftware)?
Aus meiner Sicht sollte dieser Änderungswunsch also eher Funktionserweiterungen bei der vom Rahmenwerk zur Verfügung gestellten Oberflächenberechtigungsschnittstelle enthalten!!!
Die Argumentation überzeugt.
Aber wie könnten dann solche Funktionserweiterungen aussehen? Was könnte denn zum Beispiel besagtes Plug-in „GTM für Rahmenwerk“ an Erweiterungen benötigen? Oder wäre dann die Aufgabenstellung eigentlich nur, den RW-GTM an das überarbeitete Oberflächenberechtigungskonzept anpassen zu müssen?
Das GTM-Plug-In sollte davon nicht betroffen sein. ich tippe eher auf das Rechte-Konfigurations-Plug-In aus der INOVAT-Bibliothek.
Dieses würde dann Funktionen benötigen wie:
– setze die Berechtigung für eine Funktion und eine Benutzerklasse
– speichere die aktuelle Einstellung der Berechtigungen
Die Funktionalität sollte aber eigentlich integraler Bestandteil des Rahmenwerks sein, also auch der Editor zum Bearbeiten der Rechte.
Ansonsten fallen mit momentan keine konkreten Anforderungen an die Funktionalität ein.
Ich würde Ihre Sicht der Dinge dann im NERZ-Änderungsmanagement eintragen.
Soll dann in dem Eintrag noch der Umfang der angesprochenen Funktionserweiterungen abgefragt werden? Oder ist Ihnen das eigentlich klar?
Ich sehe keine notwendigen Funktionserweiterungen, wenn das Rahmenwerk die Funktionalitäten:
– Oberflächenfunktionen anlegen/entfernen
– Berechtigung für Nutzer(Benutzerklassen) abfragen
– Anmelden auf Änderungen von Oberflächenfunktionen
– Berechtigungen über im Rahmenwerk vorhandenen Editor bearbeiten
zur Verfügung stellt.
Falls diese Funktionalität nicht reicht, wäre es schon interessant, wo noch Bedarf besteht.
Das Feature wäre relativ leicht zu implementieren, widerspricht aber eigentlich der Intention der Verwendung und Aktualisierung des Rahmenwerks.
Richtig ist, dass das Rahmenwerk den Parameter auswerten muss, um die Parameter beim korrekten Objekt zu ermitteln.
Die Information. Welches Objekt das Rahmenwerk letztendlich verwendet sollte aber nicht für andere Plug-Ins von Bedeutung sein, da die Oberflächenberechtigungs-Verwaltung ja zentraler Bestandteil des Rahmenwerks selbst ist.
Der einzige Zweck, dieses Objekt zu kennen, wäre eine Umgehung der Verwaltung des Rahmenwerks, was aber doch eigentlich kontraproduktiv im Sinne der ERZ ist und zu einer UERZ führt (Uneinheitliche Rechnerzentralensoftware)?
Aus meiner Sicht sollte dieser Änderungswunsch also eher Funktionserweiterungen bei der vom Rahmenwerk zur Verfügung gestellten Oberflächenberechtigungsschnittstelle enthalten!!!