More about Forms & Form Projects
|
| |
Introduction |
User Management Resource Administrator
Forms & Delegation introduces several new concepts.
The most important 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 non-administrative user. A good example
is a common reset password task, which requires an existing user account
to be selected and a button to confirm the selection. These 2 flows of
data can be combined into a Form using a table for the user selection and
a
button to submit the 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 will 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 below screenshot, a sample form has been loaded and
the autopreview has been enabled: |
|
 Download
the reset password demo project used on this page |
|
|
|
| The above screenshot shows a sample form with the autopreview 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 2 user interaction elements. These user interaction elements are
a table containing live users from the Active Directory (in this case a specific
Organizational Unit) and a button. |
|
|
|
| Since the table and button are the only elements that allow for user interaction,
let's view the properties of these elements. The above screenshot shows the
contents properties for the table element. This table has been configured
to show network data. The network data is setup to display
all users from a specific Organizational Unit, and only show the "Common
name" field. As you can see, a second field has also been configured,
but has a pre-defined width of 0%, making it a hidden field.
This hidden field contains the full Object Distinghuished Name for every
user listed in the first column, making it perfect for using in scripts.
Since we don't need end-users to see it, we can make it hidden and assign
a variable to it since that the script will have access to its contents. |
|
|
|
| Next, the button is the second and last element to support user interaction.
The button is simply configured to submit the form and its variables to the
script assigned to the form inside the form project. |
|
|
|
| When looking at the script, notice that the Get user (AD) script action
gets its input from the table using the Object Distinghuished Name stored
in the %ODN% variable. This variable is filled in when the user makes a selection
and click 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 are entitled to run the form. These users can be selected
from any Active Directory or Windows NT4 domain. When loading the Forms client,
your active logon will be valited 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?
|
| Of course, we are so convinced that User Management Resource Administrator
works for your environment whatever the size, we can show you the product
and its capabilities in just 30 minutes in our own test facility for free! |
|
|
|
|
|
|
|
| |
