Elements within TaskDefinition
The TaskDefinition contains several nested elements that are used to define important information for the report. The TaskDefinition always contains an Attributes map and a Signature, and usually contains a Description element and a list of RequiredRights.
The Attributes map must at minimum include the report definition.
<Attributes>
<Map>
<entry key="report">
<value>
<LiveReport title="Uncorrelated Accounts Report">
…
</LiveReport>
</value>
</entry>
</Map>
</Attributes>
Other optional attributes in the attribute map include emailIdentities, reportSortBy, reportGroupBy, disableSummary, and disableDetail, as described in the Standard Forms for Report Specification section.
The Signature contains a map of Input attributes that name all of the parameters that can be specified for the report.
<Signature>
<Inputs>
<Argument multi="true" name="correlatedApps" type="Application">
<Description>rept_input_uncorrelated_ident_report_correlated_apps
</Description>
<Prompt>report_input_correlated_apps</Prompt>
</Argument>
<Argument name="resultScope" type="Scope">
<Description>rept_input_result_scope</Description>
</Argument>
<Argument multi="true" name="emailIdentities" type="Identity">
<Description>rept_input_email_recips</Description>
</Argument>
</Inputs>
</Signature>
When a customized report instance with pre-populated parameters is saved, those parameters are saved as a part of the instance's TaskDefinition in its Attributes map. In this example, a list of Applications and a list of Email Recipients have been saved for this report instance.
<TaskDefinition created="1344453735712" id="4028460238edaba4013907aff5200ec9" modified="1344867911170" name="Uncorrelated Accounts" resultAction="Rename" subType="Identity and User Reports" type="LiveReport">
<Attributes>
<Map>
<entry key="correlatedApps">
<value>
<List>
<String>4028460238edaba401372767b6eb0d70</String>
<String>4028460238edaba40138edcfcd1102d2</String>
</List>
</value>
</entry>
<entry key="disableDetail" value="false"/>
<entry key="disableSummary" value="false"/>
<entry key="emailIdentities">
<value>
<List>
<String>4028460238edaba40138edb3571e000d</String>
</List>
</value>
</entry>
<entry key="reportColumnOrder" value="username, firstName, lastName"/>
</Map>
</Attributes>
They are passed from the customized report instance to the associated report template at run-time through the taskDefinition input arguments specified in the <Signature>
for the report.
Every report template's Signature should include input arguments for resultScope and emailIdentities, since these automatically appear on the Standard Properties window and are available for a user to specify on all reports. All other input arguments are report-specific and the remainder of the arguments in a custom report is specific to that report. The list of arguments should match the set of fields available for parameter specification on the report's Form. Report-specific arguments should include a name and type as attributes on the <Argument>
element. If the argument is multi-valued, it should also include the attribute "multi="true"."
Application arguments can include a Description and Prompt element. When a custom form (in a <ReportForm>
element) has been specified, these are ignored and can be omitted. However, if no custom form is specified, these report-specific input arguments are automatically rendered on a form page (titled Report Options) using the Prompt value as the field label and the Description value as the tool tip for the field. Both of these values can be specified as strings or as localizable message keys.
<Argument multi="true" name="correlatedApps" type="Application">
<Description>rept_input_uncorrelated_ident_report_correlated_apps
</Description>
<Prompt>report_input_correlated_apps</Prompt>
The Account Group Members report is an example of a report that relies on this automatic form rendering for its report-specific filter options.
The Description element is displayed as the Description for the report on both the Reports and My Reports lists and on the Edit Report window.
<Description>A detailed view of the uncorrelated user accounts in the system.</Description>
The RequiredRights element specifies what system right(s) a user must have to be able to see and execute the report. The required rights are specified as references to one or more SPRight objects.
<RequiredRights>
<Reference class="sailpoint.object.SPRight" id="4028460238ed9b8e0138ed9bc59d0054" name="FullAccessUncorrelatedIdentitiesReport"/>
</RequiredRights>