Durch das Section Handling wird festgelegt, welcher User bestimmte Teile (sog. Sections) innerhalb der Smartform sehen kann/darf. Diese Beschränkungen können entweder innerhalb eines ganzen Prozesses gelten oder bei einem gewissen Stand innerhalb des Prozessverlaufs. Die folgenden Rechte können vergeben bzw. entzogen werden:
In der Smartform wird der Bereich, der durch das Section Handling beeinflusst werden soll, beispielsweise mit einem DIV umschlossen und markiert somit einen abgeschlossen Teil.
Diesem DIV muss zwingend das Attribut class=„section“ mitgegeben werden. Ein Element welches das Attribut class=„section“ erhalten hat, darf keine weiteren Klassen besitzen. Die ID des DIVs kann dabei beliebig gewählt werden.
In dem folgenden Beispiel sind zwei DIV-Bereiche zu sehen:
Wobei der Inhalt innerhalb eines DIVs keine Rolle spielt und beliebig sein kann.
<div class="section" id="section1"> <label for="section1Input">Section1</label> <input id="section1Input" name="section1Input" type="text"></input> </div> <div class="section" id="section2"> <label for="section2Input">Section2</label> <input id="section2Input" name="section2Input" type="text"></input> </div>
Befindet sich die Section innerhalb einer Tabelle (<table>), so muss ein tBody(tr,td) anstatt eines DIVs benutzt werden, um die Section abzugrenzen.
Die Parameter für das Section Handling, mit welchen die Rechte zugewiesen werden, werden in Signavio für den Prozess definiert :
<section-node-mapping> <node-mapping name="Name_einer_Node_aus_dem_Prozess"> <section name="ID_der_Section_aus_der_Smartform"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> </section-node-mapping>
Für die Assignments innerhalb der read und write Elemente stehen nun folgende Möglichkeiten zur Auswahl:
Zielgruppe | Schreibweise |
---|---|
einzelne Benutzer | „user(Benutzername)“ |
Swimlanes | „swimlane(Swimlanename)“ |
Gruppe | „group(Gruppenname)“ |
Wildcard (für keinen Benutzer) | „“ |
Wildcard (für alle Benutzer) | „*“ |
Negation(dieser User darf nicht…) | „! user(…)„ |
Mehrere Angaben können getrennt durch Semikolons realisiert werden, z. B.: „group(Vertrieb);group(Controlling);user(Max.Mustermann)“
Locking kann zusätzlich zu den Assignments angegeben werden und dient als Bearbeitungssperre. Um das Locking zu implementieren muss der Parameter lockable=„true“ angegeben werden. Locking kann auf das node-mapping oder die section selbst gelegt werden. Das locking Attribut der section überwiegt immer das Attribut des node-mappings.
<section-node-mapping> <node-mapping lockable="true"> <section name="section1"> <read assignment="*"/> <write assignment="*"/> </section> <section name="section2" lockable="false"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> </section-node-mapping>
Wird nun die Smartform geöffnet, ist der Bereich standardmäßig gesperrt, jedoch befindet sich hinter den gelockten Elementen ein Stiftsymbol :
Über einen Klick auf das Symbol kann das gelockte/gesperrte Feld entsperrt werden und somit auch bearbeitet werden. Das Feld ist nach dem Klick für alle anderen User gesperrt, d.h. öffnet ein anderer Benutzer die Smartform ist es für ihn nicht möglich das für ihn gesperrte Feld ebenfalls zu entsperren und zu bearbeiten während das Feld von dem ersten User entsperrt ist. Damit wird verhindert dass eingegebene Daten versehentlich von einem anderen Nutzer überschrieben werden. Das Feld kann erst dann wieder von anderen Nutzern entsperrt werden, wenn der Benutzer der das derzeitige Bearbeitungsrecht besitzt die Smartform speichert und schließt.
Ist lockable auf false gesetzt, wird vor der einer Section ein Stiftsymbol angezeigt, solange sich der Prozess nicht an der Node befindet die in dem zugehörigen NodeMapping angegeben wurde. Befindet sich der Prozess dann an der Stelle, die angegeben wurde, so wird das Stiftsymbol ausgeblendet. Sollen nun alle Stiftsymbole ausgeblendet werden, so muss ein globales NodeMapping angegeben werden, in welchem alle Sections einmal definiert werden und ein Assignment bekommen. Soll sich an der Funktionsweise der Smartform nichts ändern, so reicht es in dem globalen NodeMapping jeder Section eine Wildcard zu geben.
Sollen bereits vor Start der Instanz Bereiche eingegrenzt werden, so muss ein NodeMapping eingefügt werden, welches den Namen des Starts trägt. Ist kein Name für den Start angegeben, so bekommt der Start standardmäßig den Namen „StartEvent_1“ und das Ende den Namen „EndEvent_1“, dieser kann dann im NodeMapping benutzt werden
Das folgende Bild zeigt den Ausgangszustand der Smartform ohne Section Handling (alles ist sichtbar und bearbeitbar):
Der obere Teil befindet sich in der ersten Section und der untere Teil befindet sich in der zweiten Section. Bei den Beispielen werden alle auf einen User als Beschränkter ausgelegt, es ist jedoch genauso möglich alle folgenden Beispiele mit den oben genannten Assignments durchzuführen. Es können nun die folgenden Szenarien mit Hilfe des Section Handlings erzeugt werden:
Nun soll der obere Teil nur für einen bestimmten User sichtbar und bearbeitbar sein. Die dafür benutzten Section Handling Parameter könnten wie folgt aussehen:
<section-node-mapping> <node-mapping> <section name="section1"> <read assignment="user(TIM)"/> <write assignment="user(TIM)"/> </section> <section name="section2"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> </section-node-mapping>
Die Smartform würde für den User TIM nach wie vor aussehen wir der Ausgangszustand für alle anderen jedoch würde sich das folgende Bild ergeben:
Wie man sieht ist nur der untere Teil der Smartform sichtbar.
Nun soll der obere Teil zwar sichtbar sein, jedoch nur für den User TIM bearbeitbar sein. Die dafür benutzten Section Handling Parameter könnten wie folgt aussehen:
<section-node-mapping> <node-mapping> <section name="section1"> <read assignment="*"/> <write assignment="user(TIM)"/> </section> <section name="section2"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> </section-node-mapping>
Daraus ergibt sich wiederrum das folgende Bild für alle anderen User, die die Smartform öffnen wollen: Die obere Section ist nun zwar für alle sichtbar, jedoch kann in das Textfeld nichts eingegeben werden, da der read Parameter nicht gesetzt ist.
Die Beschränkungen in den bisherigen Beispielen waren global und gelten für den gesamten Prozess.Nun kann man die Beschränkungen aber auch nur an bestimmten Stellen in einem Prozess geltend machen.
Nun soll das erste Beispiel, in dem nur die zweite Section sichtbar ist so erweitert werden, dass die Beschränkung nur dann gilt, wenn sich der Prozessfortschritt auf einer bestimmten Node befindet.
Dies soll anhand des folgenden Prozesses verdeutlicht werden:
Das gewünschte Ziel ist, dass solange sich der Prozess auf der Node A befindet nur der User TIM den oberen Teil der Smartform sehen darf. Sobald sich der Prozess auf Node B befindet darf zwar jeder den oberen Teil sehen, aber nicht bearbeiten. Hierfür müssen für jede Node die section Parameter angegeben werden .Die Parameter um dieses Ziel zu erreichen sind die folgenden:
<section-node-mapping> <node-mapping name="A"> <section name="section1"> <read assignment="user(TIM)"/> <write assignment="user(TIM)"/> </section> <section name="section2"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> <node-mapping name="B"> <section name="section1"> <read assignment="*"/> <write assignment="user(TIM)"/> </section> <section name="section2"> <read assignment="*"/> <write assignment="*"/> </section> </node-mapping> </section-node-mapping>
Während des ganzen Prozesses kann der User TIM die gesamte Smartform einsehen und bearbeiten da für ihn keine Beschränkungen angegeben sind. Befindet sich der Prozess auf der Node A ergibt sich für alle anderen das folgende Bild wenn die Smartform geöffnet wird: Nur der untere Teil ist sichbar.
Wird die Aufgabe nun erledigt und der Prozess schreitet auf Node b voran, kann der User TIM weiterhin alles sehen. Für alle anderen sieht die Smartform so aus: Der obere Teil ist nicht bearbeitbar, aber sichtbar.
In der Smartform Suche werden nur die Read-Expressions angewendet welche für den ganzen Prozess gültig sind.
Das heißt:
Wenn ich die Section generell sehen darf, darf ich auch danach suchen und vice versa.