Section Handling
- Betül Kara (Deactivated)
- Martin Oehm
General
Which user may see specific parts (so-called sections) within the form is determined by the Section Handling. These restrictions can either apply in a whole process or at a certain level in the course of the process. The following permissions can be granted or revoked:
write permission
read permission
The parameters for the Section Handling, with which the rights are assigned, are defined on the start event of the process model in the area 'Section Definition'.
Preparation of the form
The part which should be affected by the Section Handling will be enclosed for example with DIV in the form, and therefore marks a completed part.
The DIV should be given necessarily the attribute class=“section” and the name of the ID can be individually defined. An element, which has the attribute class = “section”, can not have any other classes.
Two DIV-areas are seen in the following example:
DIV with the ID=“section1”, contains:
Label 'Section1'
Input 'Section1'
DIV with the ID=“section2”, contains:
Label 'Section2'
Input 'Section2'
The content within a DIV is irrelevant and may be optional.
<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>If the Section is inside a table (<table>), a tBody(tr,td) should be used instead of a DIV, for defining the Section.
Create a Section Handling
The following sections describe in detail how to implement read and write permissions.
Parameters
The Section Handling is written in XML (Extensible Markup Language). The general structure is as follows:
<section-node-mapping>
<node-mapping name="Name_of_a_node_from_the_process">
<section name="ID_of_the_Section_from_the_form">
<read assignment="*"/>
<write assignment="*"/>
</section>
</node-mapping>
</section-node-mapping>
Detailed description of each parameter used for implementing a Section Handling:
Parameter | Description |
|---|---|
| The section-node-mapping element is the major component of the Section Handlings, where the rules of the restriction are defined. |
| The attribute name can be given optionally here. This makes it possible to configure the restrictions that they apply only at a certain level within the process, e.g. User A is allowed to see the textarea, if the form is opened during the first node but not once the process is on node B. |
| This element must contain the attribute name, which indicates the ID of the desired Section of the form. Within the Section element, now the rights can be distributed that will apply for the specified Section. |
| Via the read element, it can be defined, who can see the content within a section. The people are determined via the assignment attribute. |
| Via the write element, it can be defined, who can work on the content within a section (e.g. write in a textarea). The people are determined via the assignment attribute. |
Assignment
The following options are available for the assignments within the read and write elements:
Target group | Notation |
|---|---|
individual user | "user(username)" |
swimlanes | "swimlane(swimlanename)" |
groups | "group(groupname)" |
wildcard (for no user) | "" |
wildcard (for all users) | "*" |
negation (this user can not...) | "! user(username)" |
Multiple selections can be realized by semicolons, e.g.: “group(Sales);group(Controlling);user(johndoe)”
Locking
Locking can also be specified to the assignments and is used as a lock for editing.
Locking with pen symbol
For implementation the locking, the parameter lockable=“true” must be declared. Locking can be place on the node-mapping or the section itself. The locking attribute of the section always outweighs the attribute of 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>
If now the form is opened, the area is locked by default, but above the locked 'Section1' is a pen symbol:
Via a click on the symbol, the locked array can be unlocked and therefore edited.
The array is locked for all other users after clicking, which means if another user opens the form it is not possible to unlock and edit the locked section while the array is unlocked by the first user. This is for preventing that input data are accidentally overwritten by another user. The field can only be unlocked by other users, if the user, who owns the current edit permission, saves and closes the form.
Remove pen symbols
If lockable is set to false, a pen symbol appears in front of a section as long as the process is not at the node which was specified in the associated node-mapping. If the process is then at the stage which is specified, the pen symbol will be removed. If now all pen symbols shall be removed, a global Node Mapping must be specified, in which all sections are defined once and get an assignment. If there is no change on the functioning of the form, it is enough to give a wildcard to every section in the global Node Mapping.
Examples
The following image shows the initial state of the form without Section Handling (everything is visible and editable):
The upper part is in the first section and the lower part in the second section. In the examples all are designed for one user as limited, but it is also possible to carry out all following examples with the assignments explained in paragraph Assignment. The following scenarios can now be generated by using the Section Handling.
Section visible and editable only for certain users
Now, the upper part shall be visible and editable only for a specific user. The used Section Handling parameter for this, might look like this:
The form would be look like the initial state for the user John Doe, but all others can only read and write into 'Section2'.
Section editable only for certain user
Now the upper part shall be visible, but editable only for the user John Doe. The used Section Handling parameter for this, might look like this:
The 'Section1' is now visible for everybody, but nobody can write into this input field, except the user John Doe.
Section restriction on limited area within the process
The restrictions in the previous examples were global and apply to the entire process. Now it is possible to assert the restriction at certain points in the process. The first example, where only the second section is visible, shall be extended now, that the restriction only applies, when the progress of the process is at a particular node. This will be illustrated by the following process:
The desired goal is, that as long as the process is at node 'Create personal file' only the user John Doe is allowed to see the upper part of the form. Once the process is at node 'Organize workplace and first working day' everybody is allowed to see the upper part but can not edit. Therefore for every node a section parameter must be specified. The parameters for achieving the goal are the following:
During the whole process, the user John Doe can view and edit the entire form, because there are no restrictions.
In the task 'Create personal file' only the 'Section2' of the form will be displayed to any other user.
If this task is done and the process proceeds to the task 'Organize workplace and first working day', the user John Doe can still see everything. For everybody else, the upper part of the form is not editable but visible.
Section Handling at instance start
If parts should be limited at instance start, a node-mapping with the name of the start event must be inserted. If no name is given for the start, the start gets the name “StartEvent_1” by default and the end the name “EndEvent_1”.
How does the Section Handling behave in the form search?
In the form search, only the read-expressions are used which are valid for the whole process.
If the section can be seen in general, it can be searched and vice versa.
© TIM Solutions GmbH | AGB | Datenschutz | Impressum