More about Forms & Form Projects
|
| |
Introduction |
User Management Resource Administrator Forms & Delegation introduces several new concepts in managing the user lifecycle flow. The most important of these concepts is the inclusion of Forms. In its most basic state, the form is the graphical representation of a user management task, which can be delegated to a user with non-administrative network rights. The most common example is a password reset, which requires an existing user account be selected and a button to confirm the selection. These two flows of data can be combined into a Form using a table to select the user and a button to submit that selection. The table selection and the text in the input box can be loaded into variables available in the script attached to the Form. When a Form and script are combined we call it a Form project.
|
 |
| |
The Form Project Builder
|
| User Management Resource Administrator Forms & Delegation includes a Form development studio to create and customize forms. A form is regarded as input for a script; together the form and script are called the form project. As you can see in the screenshot below, a sample form has been loaded and the auto-preview has been enabled: |
|
 Download
the reset password demo project used on this page |
|
|
|
| The screenshot above shows a sample form with auto-preview enabled. The main window contains the form elements in the upper area and the script with properties in the lower area. This is a basic form displaying some graphics, text, and two user interaction elements. These user interaction elements are a table containing live users from Active Directory (in this case a specific Organizational Unit) and a button. |
|
|
|
| As the table and button are the only elements that allow for user interaction, we will start by viewing their properties. The screenshot above shows the content properties for the table elements. This table has been configured to show network data. The network data is set up to display all users from a specific Organizational Unit, and only show the "Common
name" field. A second field has also been configured, but it has a pre-defined width of 0%, making it a hidden field. This hidden field contains the full Object Distinguished Name for every user listed in the first column, making it perfect for use in scripts. Since end-users do not need to see this field, it is hidden and assigned a variable since the script will have access to its contents. |
|
|
|
| The button is the second and final element to support the user interaction. The button is then configured to submit the form and all of its variables to the script, which is assigned to the form inside the form project. |
|
|
|
| When looking at the script, notice that the "Get user (AD)" script action receives its input from the table using the Object Distinguished Name stored in the %ODN% variable. This variable is filled in when the user makes a selection and clicks the submit button. |
|
|
|
| Also notice that the "Edit user (AD)" uses a fixed password, "tools4ever"
to reset the password. This script action uses the user object resolved by
the "Get user (AD)" script action. |
|
|
|
| The final configuration step for a form project is to assign the user accounts and/or groups who will be entitled to run the form. These users can be selected from any Active Directory or Window NT4 domain. When loading the Forms client, your active logon will be validated and checked against this setting. |
|
| |
The final result in the Forms client
|
| When the form project has been completed and delegated to an end-user, the result in the Forms client will look similar to the screenshot below: |
|
|
|
I have some questions, can you guide me through?
|
| We are absolutely confident that User Management Resource Administrator will work for your environment -whatever the size; we can show you the product and all its capabilities in just 30 minutes on our test server for free! |
|
|
|
|
|
|
|
| |
