Report Forms

The layouts and contents of report-specific form pages are specified within a Form object, referenced by the report XML in a <ReportForm> element, nested within the <LiveReport> report definition. The Form object must be created and imported into IdentityIQ separately and is referenced by name.

Each <Section> defines a separate page on the Edit Report window. The page name, shown in the Sections list and at the top of the form, is specified as the Section's label attribute.

Copy 
   <Form name="Uncorrelated Accounts Report Custom Fields">
      <Section label="Uncorrelated Accounts Parameters" name="customProperties">
<Field displayName="report_input_correlated_apps" filterString="logical==false &amp;&amp; authoritative==false" helpKey="rept_input_uncorrelated_ident_report_correlated_apps" name="correlatedApps" type="Application" value="ref:correlatedApps"/>
      </Section>
    </Form>

Reports with large numbers of available parameters often include multiple report-specific-parameter pages, specified as multiple Sections in the Form XML, to group the parameters by category.

Copy 
 <Form name="Identity Report Options Form Skeleton">
    <Section columns="2" label="rept_priv_access_section_priv_account_attrs" name="Priviledged Account Attributes">
       <Attributes>
          <Map>
            <entry key="subtitle" value="rept_priv_access_section_instructions"/>
          </Map>
       </Attributes>
     </Section>
    <Section columns="2" label="rept_priv_access_section_account_props" name="Account Properties">
        <Field columnSpan="1" displayName="rept_identity_roles_field_app" helpKey="rept_identity_roles_helpN_app" multi="true" name="applications" type="Application" value="ref:applications"/>
    </Section>
    <Section columns="2" label="rept_priv_access_section_identity_props" name="Identity Properties"/>
    <Section columns="2" label="rept_priv_access_section_identity_extended_props" name="Identity Extended Properties"/>
</Form>

Several of the sections in this example XML do not contain any Field definitions. This is because this report uses an initialization rule to create the form fields for those sections based on system data. See Initialization Script or Rule for more information on these dynamic forms.

These are the attributes that can be specified for the Section element.

Section Attribute

Usage

label

The label for the form; can be a string or a localizable message key

name

Name for the section; must be unique per form; used programmatically but not displayed on the UI Edit Report window

Columns

Used to specify the number of columns in which fields should be displayed; fields are displayed in the order they are listed within the section, with one field added to each column in a repeating pattern; for example, in a 2-column layout, 5 fields would be displayed like this:

Field 1 Field 2
Field 3 Field 4
Field 5

This attribute can be omitted for a one-column display.

Fields on each form are specified as nested <Field> elements within each <Section>. Important report-form attributes on the Field element are described below.

Copy 
Field displayName="report_input_correlated_apps" 

filterString="logical==false &amp;&amp; authoritative==false" helpKey="rept_input_uncorrelated_ident_report_correlated_apps" name="correlatedApps" type="Application" value="ref:correlatedApps"/>

Field Attribute

Usage

displayName

The label for the field. Can be a string or a localizable message key.

helpKey

The tool tip for the field. Can be a string or a localizable message key.

name

Name for the field and must be unique per form.

type

Field type. If this entry is an object, it is automatically created as a suggest, allowing the user to select from the system's existing objects of that type.

filterString

A filter string that restricts the set of objects presented to the user for selection. Only applies to objects that are presented as suggest boxes.

value

A reference to the XML input parameter from which to retrieve the starting / default value for the field. This is how the saved values in customized report instances are populated on the form when those instances are viewed in the Edit Report window. Input parameters to the TaskDefinition XML are specified in its signature, as described in Report Signature: Passing Data from Saved Report Instances below.

postBack

A flag indicating if the form should be submitted when the field value changes.This causes the form to be reloaded and any initialization actions to be performed. This flag is important if an initializationScript or Rule or an ExtendedColumnScript or Rule needs to run to add or remove fields on the form or columns on the report based on this field value.

AllowedValuesDefinition

This is specified as a nested element to provide a list of values from which the form user can select. See the User Activity Report for an example (excerpted below).

<Field columnSpan="1" displayName="label_action" helpKey="rept_input_app_activity_report_action" multi="true" name="action" type="string" value="ref:action">

<AllowedValuesDefinition>

<Script>

<Source>

import sailpoint.object.*;

 

List items = new ArrayList();

for(ApplicationActivity.Action action : ApplicationActivity.Action.values()) {

List l2 = new ArrayList();

l2.add(action.toString());

l2.add(action.getMessageKey());

items.add(l2);

}

return items;

</Source>

</Script>

</AllowedValuesDefinition>

Custom report forms are presented to users in the Edit Report window, along with the Standard Properties page and the Report Layout page. The Standard Properties and Report Layout pages are standard components of the report architecture and are automatically presented for any standard or custom report that implements the LiveReport architecture, whether or not the report references a custom form for report-specific parameters. The Standard Properties page is always presented first and the Report Layout page is always last; report-specific form pages are inserted between these two on the Edit Report window.