In den Ausgaben Januar bis März 2006 von Expert ´s inside Lotus Notes/Domino haben wir die grundlegenden Techniken der Anwendungsentwicklung mit dem Workplace Designer betrachtet. Neben der Erstellung von Masken, Schemas und Scriptbibliotheken sind wir auf die Realisierung von Antwortdokumenten und den Zugriff auf sowie die Filterung von Dokumenten in Ansichten eingegangen. Die einzelnen Techniken wurden Schritt für Schritt am Beispiel einer Anwendung zur Verwaltung von Büchern erprobt.
Der vorliegende Artikel stellt die verschiedenen Möglichkeiten der Zugriffssteuerung vor und zeigt den Einsatz der Leser- und Editorenfelder am Beispiel. Wie in den bisherigen Artikeln gehen wir dabei entsprechend dem Ansatz des Workplace Designer – Heranführung von Notes Programmierern an die Entwicklung von Anwendungen für den Workplace Portal Server – von den aus dem Domino Designer bekannten Möglichkeiten aus.
Die Steuerung der Zugriffsrechte spielt in dokumentbasierten Anwendungen eine herausragende Der Zugriff auf die Datenbank wird über die Zugriffskontrollliste (Access Control List – ACL) gesteuert. Masken und Ansichten besitzen Lesezugriffslisten. Daneben kann das Erstellen von Dokumenten mit den Erstellungszugriffslisten der Masken geregelt werden. Auf Dokumentebene stehen mit Leser- und Autorenfeldern zwei spezielle Feldtypen zur Verfügung.
Im IBM Workplace Designer finden Sie zwei dieser Verfahren. Für die Zugriffssteuerung auf Basis der Dokumente stehen Leser- und Editorenfelder zur Verfügung. Auf der Ebene der Komponente arbeiten 5 Zugriffsrechte ähnlich der ACL einer Notes-Datenbank mit den Rollen der Schablonen des Workplace Server zusammen.
Leser- und Editorenfelder
Die von Lotus Notes bekannten Autorenfelder heißen im Workplace Designer Editorenfelder (im Folgenden schließt der Begriff Editorenfelder im Zusammenhang mit Lotus Notes den Begriff Autorenfelder mit ein). Die Wirkungsweise der Leser- und Editorenfelder sind in den beiden Entwicklungsumgebungen jedoch sehr ähnlich. Analog zu Lotus Notes gilt:
-
Benutzer, deren Name sich im Leserfeld befindet, können das Dokument lesen.
-
Benutzer, deren Name im Editorenfeld steht, können das Dokument bearbeiten.
-
Leere Leser- oder Editorenfelder haben keine Wirkung.
-
Leser- oder Editorenfelder können eine Vielzahl von Namen enthalten.
-
Besitzt ein Benutzer nicht zumindest Leserechte über die ACL der Komponente, kann er das Dokument auch dann nicht lesen, wenn er im Leserfeld steht.
-
Besitzt ein Benutzer nicht zumindest Editorenrechte, kann er ein Dokument trotz Eintrag in einem Editorenfeld nicht bearbeiten.
Zu beachten ist, dass im Unterschied zu Lotus Notes ein Benutzer mit Editorrechten auf Komponentenebene ohne einen Eintrag in einem nichtleeren Editorfeld das Dokument nicht bearbeiten kann.
Im Gegensatz zur Wirkungsweise unterscheidet sich die technische Umsetzung in den beiden Entwicklungsumgebungen. Im Domino Designer stehen Ihnen für die Erstellung von Leserund Autorenfeldern zwei spezielle Feldtypen zur Verfügung. Im Workplace Designer wird ein anderer Lösungsansatz genutzt. Die Werte werden mit JavaScript über ein Objekt der Klasse gesetzt. Dieses Objekt beinhaltet eine Liste mit allen Leser- und Editorenfeldern eines Dokuments. Die Klasse DBREList stellt Methoden für die Manipulation der Werte der Leser- und Editorenfelder zur Verfügung (Tabelle 1).
|
Methode |
Beschreibung |
|
Add(<Feldname>:String, <Wert>:String) |
Die Methode add fügt das Leser- oder Editorenfeld <Feldname> mit dem Wert <Wert> in das Dokument ein. |
|
addField(<Feldname>:String) |
Zum Einfügen eines leeren Leser- bzw. Editorenfeldes verwenden Sie die Methode addField. |
|
contains(<Wert>:String) |
Über die Methode contains prüfen Sie das Vorhandensein eines bestimmten Wertes in einer Liste. |
|
getFieldNames() |
Diese Methode gibt alle Feldnamen zu |
|
getFieldValues(<Feldname>:string) |
Die Methode liefert alle Werte eines Feldes. |
|
hasValues() |
Nutzen Sie diese Methode, um festzustellen, ob die Liste Werte enthält. |
|
remove(<Feldname>:String, <Wert>:String) |
Zum Entfernen eines Feldes von der Liste steht Ihnen die Methode remove zur Verfügung. |
|
removeField(<Feldname>:String) |
Diese Methode entfernt nur den Feldinhalt des angegebenen Feldes. |
|
setFieldValue (<Feldname>:String, <Werte>:String[ ]) |
Die Methode setFieldValues setzt alle übergebenen Werte für das |
Für den Zugriff auf die in einem Dokument vorhandenen Leser- und Editorenfelder verfügt die Klasse DBDocument über die beiden Methoden getReaders und getEditors. Diese geben jeweils ein Objekt der Klasse DBREList zurück. Mit der Verwendung der jeweiligen Methode wird für eine Objektvariable der Klasse DBREList bestimmt, ob sie Leser- oder Editorenfelder repräsentiert:
var editors : DBREList;
editors = document.getEditors();
Im obigen Beispiel wird die Objektvariable editors der Klasse DBREList deklariert. Mit der Zuweisung der im Dokument vorhandenen Editorenfelder steht sie im Programmcode für Editorenfelder. Wird im Anschluss die Methode add auf die Variable angewandt, werden der übergebene Feldname (editors1) und dessen Wert (hier der Inhalt der Variablen name) als Editorfeld im Dokument abgelegt:
editors.add("editors1", name);
Analog verhält es sich mit Lesefeldern:
var readers : DBREList;
readers = document.getReaders();
readers.add("readers1", name);
Für das Setzen der Werte der Leser- bzw. Editorenfelder bieten sich zwei Varianten an. Zum einen kann dies automatisch durch das Einfügen des benötigten JavaScript-Programmcodes zu Maskenereignissen erfolgen. Mögliche Ereignisse sind dabei onPostNewDocument, onPostOpen- Document sowie onQuerySaveDocument. Sollen die Werte jedoch manuell gesetzt werden, so hinterlegen Sie den Programmcode im Ereignis onClick einer Schaltfläche.
Beachten Sie, dass für die Verwendung von Leser- und Editorenfeldern in einer Maske sich darin nicht zwingend physische Felder für die Speicherung der Werte befinden müssen. Dieses Prinzip ist aus Lotus Notes bekannt. Auch dort beinhalten Dokumente Felder, für welche kein physisches Feld zur Anzeige der Werte in einer Maske vorhanden ist. Jedoch gilt dies in Lotus Notes nicht für Leser- und Autorenfelder.
Anwendung im Beispiel
In unserem Beispiel wollen wir die betrachteten Lösungswege in der Maske Anmerkungen umsetzen. Die Anmerkungsdokumente zu den Büchern sollen nur vom jeweiligen Autor bearbeitet werden können. Zusätzlich sind die Dokumente für die anderen Benutzer verborgen, bis der Autor das Dokument freigibt. Der Leser eines Buches hat damit die Möglichkeit, seine Gedanken bereits beim Lesen zu hinterlegen, ohne dass andere Benutzer diese schon einsehenkönnen.
Als einfache Form des Debugging fügen wir zwei Felder zur Anzeige der aktuellen Werte der Leser- und Editorenfelder in die Maske ein. Erstellen Sie in der Maske Anmerkungen eine Tabelle mit zwei Zeilen und zwei Spalten. Fügen Sie in diese je zwei UI Controls vom Typ Label und vom Typ Computed Field ein. Die Label dienen der Anzeige der beschreibenden Texte Leser beziehungsweise Editoren. Verwenden Sie für das erste berechnete Feld den Programmcode
document.getReaders();
Aktivieren Sie dazu auf dem Register Values des Eigenschaftsfensters des Feldes die Auswahl JavaScript. Den Programmcode geben Sie direkt im Eigenschaftsfenster oder im JavaScript-Editor nach einem Klick auf die Schaltfläche Script Editor ein. Für das zweite berechnete Feld verwenden Sie entsprechend
document.getEditors();
Zur Freigabe der Dokumente durch den Autor benötigen wir eine Schaltfläche. Erstellen Sie diese in der Nähe des berechneten Feldes zur Anzeige der Lesefelder. Legen Sie für die Schaltfläche einen Namen und als Beschriftung Freigeben fest. Einen möglichen Aufbau der Maske sehen Sie in Bild 1.
Wie wir bereits weiter oben ausgeführt haben, sind die berechneten Felder zur Anzeige der Werte der Leser- und Editorenfelder nur optional und dienen lediglich der optischen Kontrolle. Das Setzen der Werte erfolgt über JavaScript-Programmcode. Wir wollen dafür das Ereignis on- PostNewDocument der Maske Anmerkungen nutzen. Beim Erstellen eines neuen Dokuments mit dieser Maske soll der Name des aktuellen Benutzers sowohl in das Leser- als auch in das Editorenfeld eingetragen werden. Öffnen Sie im Eigenschaftsfenster die Eigenschaften der Maske und wechseln Sie auf das Register Events (Bild 2).
Wählen Sie das Ereignis onPostNewDocument, als Programmmethode JavaScript, und geben Sie im JavaScript-Editor den benötigten Programmcode ein (Listing 1). In diesem wird nach der Deklaration der Variablen der aktuelle Benutzername ermittelt und in das Lesefeld readers1 sowie in das Editorenfeld editors1 mit der Methode add eingetragen (Bild 3):
// Auslesen der aktuellen Editorenliste – Typzuweisung Editor
var editors : DBREList;
editors = document.getEditors();
// Auslesen der aktuellen Leserliste – Typzuweisung Leser
var readers : DBREList;
readers = document.getReaders();
// Name des aktuellen Benutzers ermitteln
var user : DirectoryUser;
var name : string;
user = context.getUser();
name = user.getDistinguishedName();
// Bearbeitung des Dokuments auf den aktuellen Benutzer beschränken
editors.add("editors1", name);
// Leserecht auf den aktuellen Benutzer beschränken
readers.add("readers1", name);
editors.add("editors1", name);
readers.add("readers1", name);
Für die Freigabe des Dokuments verwenden wir im Ereignis onClick der Schaltfläche Freigeben folgenden Programmcode:
var readers : DBREList;
readers = document.getReaders();
readers.removeField("readers1");
document.save();
In diesem wird die Liste der Leserfelder ermittelt und danach mit der Methode remove das Leserfeld readers1 entfernt. Da die Liste keine weiteren Einträge hat, ist das Dokument danach für alle Benutzer zugänglich. Der Wert im Editorenfeld bleibt jedoch erhalten, so dass nur der Ersteller das Dokument bearbeiten kann. Andere Benutzer bekommen es im Lesemodus angezeigt (Bild 4).
Rollen auswerten
Voraussetzung für den Zugriff auf die Dokumente ist das Zugriffsrecht auf die Komponente auf dem Workplace Portal Server. Für die Zugriffssteuerung auf dem Level der Komponente bietet der Workplace Designer fünf Rollen (Tabelle 2). Diese Rollen entsprechen den Zugriffsebenen in der ACL einer Notes-Datenbank und dürfen nicht mit den dort ebenfalls möglichen Rollen verwechselt werden.
|
Rolle |
Zugriffsrecht |
|
No Access |
Benutzer mit dieser Rolle haben kein Zugriffsrecht. |
|
Reader |
Wird einem Benutzer diese Rolle zugewiesen, kann er vorhandene Dokument lesen, jedoch keine neuen erstellen. Sind im Dokument nichtleere Leserfelder enthalten, muss der Benutzer zusätzlich in diesen aufgeführt sein, um das Dokument lesen zu können. |
|
Author |
Autoren können eigene Dokumente erstellen, bearbeiten und löschen. Des Weiteren können sie die Dokumente anderer Benutzer lesen. Das Vorhandensein von Leser- und Editorenfeldern kann diese Rechte einschränken. |
|
Editor |
Benutzer mit der zugeordneten Rolle Editor können alle vorhandenen Dokumente lesen, bearbeiten und löschen sowie eigene Dokumente erstellen. Das Vorhandensein von Leser- und Editorenfeldern kann diese Rechte einschränken. |
|
Administrator |
Die Rolle Administrator ermöglicht das Erstellen eigener Dokumente sowie das Lesen, Bearbeiten und Löschen aller vorhandenen Dokumente einer Anwendung. Das Vorhandensein von Leser- und Editorenfeldern schränkt dieses Rechte nicht ein. |
Die Verwendung der Rollen im Workplace Designer unterscheidet sich stark von der Nutzung der Zugriffsebenen in Lotus Notes. Während dort die Bearbeitung der ACL direkt für die Datenbank erfolgt, ist dies im Workplace Designer nicht möglich. Hier müssen Sie eine Schablone auf dem Workplace Server erstellen, welche das Portlet (die Komponente nach dem Deploymentprozess) auf einer Seite verwendet. Schablonen besitzen ebenfalls Rollen.
Per Standard existieren nur zwei Rollen: Moderatoren und Mitwirkende (in der englischen Version Moderator und Contributor). Zusätzlich können Sie weitere Rollen erstellen. Diesen Rollen der Schablone ordnen Sie die Rollen des Workplace Designer zu, zum Beispiel Moderator (in Schablone) = Administrator (in Workplace Designer). Wollen Sie also alle fünf Rollen des Workplace Designer benutzen, müssen auch in der Schablone fünf Rollen vorhanden sein.
Erstellen Sie nun auf Basis der Schablone eine Anwendung, übernimmt diese die Einstellungen für die Rollen. Werden jetzt die registrierten Benutzer den verschiedenen Rollen zugeordnet, greifen in dem Portlet die Rollen des Workplace Designer.
Zusammenfassend die Vorgehensweise zur Nutzung der Zugriffsteuerung auf dem Level der Komponente im Workplace Designer:
-
Führen Sie den Deploymentprozess für ihreim Workplace Designer entwickelte Komponente aus, um auf dem Workplace Server das Portlet zu erzeugen.
-
Melden Sie sich auf dem Workplace Server an und erstellen Sie eine Schablone.
-
Fügen Sie in der Schablone eine neue Seite ein und dieser das Portlet hinzu.
-
Stellen Sie für die Seite die Beziehungen zwischen den Rollen der Schablone und den Standardrollen des Workplace Designer her.
-
Erstellen Sie basierend auf der Schablone eine Anwendung.
-
In der Mitgliederverwaltung der Anwendung ordnen Sie die registrierten Benutzer den verschiedenen Rollen zu.
Die Erstellung von Schablonen und deren Anpassung wird in dem Artikel „Schablonen in Workplace“ dieser Ausgabe von Expert´s inside Lotus Notes/Domino behandelt.
Verwendung der Rollen in der Komponente
Wie verwenden Sie nun die Rollen des Workplace Designer in der Komponente? Eine typische Anwendung ist das Anzeigen beziehungsweise Verbergen von Feldern, Ansichten und Schaltflächen in den Masken. Über einen JavaScript-Programmcode wird dabei geprüft, ob der aktuelle angemeldete Benutzer eine bestimmte Rolle besitzt. Ist dies nicht der Fall, wird das betreffende Gestaltungselement nicht angezeigt.
In unserer Beispielanwendung wollen wir die Anzeige der Schaltfläche Bereiche verwalten in der Maske Buchliste vom Besitz der Rolle Administrator abhängig machen. Öffnen Sie dazu die Maske Buchliste. Wählen Sie die Schaltfläche Bereiche verwalten. Auf dem Register Basics im Eigenschaftsfenster der Schaltfläche ändern Sie für Visible die Einstellung auf Computed (Bild 5).
In dem sich öffnenden JavaScript Editor geben Sie den Programmcode des Listings 2 ein. In diesem werden der aktuelle Benutzer und die ihm zugeordneten Rollen ermittelt. Anschließend wird geprüft, ob er die Rolle Administrator besitzt. In Abhängigkeit des Ergebnisses wird die Schaltfläche Bereiche verwalten angezeigt oder nicht. Beachten Sie, dass im Gegensatz zum Domino Designer eine Positivüberprüfung erfolgt („anzeigen wenn“ statt „verbergen wenn“).
var user = context.getUser();
var roleList = user.getRoles();
for (r in roleList){
if (r.equals("Administrator"))
return true;
}
return false;
Neben der Auswertung der Rollen mittels JavaScript greifen diese auch wie bereits weiter oben erläutert bei der Verwendung der Leserund Editorenfelder.