Posted by Mont Rothstein on 04 December 2013 08:53 AM
This document outlines how to format Field Paths. Field Paths are used in Reports and Request Type Definition Files (Visio files) to access data.
A Field Path is a dot '.' separated series of data fields. They provide access to both standard and custom data fields by navigating the Adams data structure. To see a list of available fields see: Field Path List. Note, when a Field Path references a field name that includes a dot as part of the name, two dots need to entered in the Field Path where the field name has one. Two dots in a Field Path tells Adams that the dot is part of the field name not a path separator.
The parent. and child. values do not change, but the path and field values in the <chevrons> will need to correspond to the the correct path and field.
All field paths are describing a path from an item (Folder, Asset, Request, Property Item, etc.) to a data field.
In a Report Template the item being processed is the starting point for the field path. A report Section can process a different item that the parent (main report or section) by using the ReportOn parameter to access related items. For example a report could be processing a Folder and a section within that report might process the Assets for the folder. Field Paths in the main report would start with the Folder and Field Paths inside the section would start with an Asset.
Within a Request all Field Paths are related to the current request. Within a Visio file each tab is a Request Type and thus any Field Paths on that tab start with a Request of that type and move out from there.
How Field Paths Work
A field path with a single item (no dot) would be referring to a field on the item.
Folder Ex: Name; FolderNumber; Assets; Requests; etc.
Request Ex: AssignedTo; RequestedBy; Status; Conclusion; etc.
The first <field> refers to a field on the item being processed. In this case the first <field> must reference a valid Item itself (ex: Folder, Asset, Property Item, etc.). The second <field> then refers to a field on the item referenced by the first field.
Ex 1: The item being processed is an Asset and we want to access the folder number for the folder/case that asset is part of.
"Folder" references the folder field on the Asset. "FolderNumber" references the folder number field on the Folder.
Ex 2: The item being processed is a request and we want to access the crime type for the folder/case the request is part of.
"Folder" references the folder field on the Request. "Crime" references the crime field on the Folder.
To see a list of available fields see: Field Path List
Request Specific Field Path Options
Requests have several field path options that are not available when processing other types of items.
To refer to a step within the Request and a field of that step place an @ in from of the step name.
If the Request has a parent request then the parent request, and all of its data, can be accessed by using the "parent" special field name.
child.<subprocess key>.<field path>
If a Request has a sub-request for which it must wait then it can access that sub-request's data by using the "child" special field name and the Key.
For don't wait sub-requests the Key can be used in reports to access all of the sub-requests.
A hyperlink/URL to open an existing request in another window can be provided to the user by using the "link" special field name. This is most commonly used in conjunction with the "parent" special field name.
Custom Field Type: Exhibit
When the exhibit datatype is used it can represent different types of data. It can be an Asset a Property Item or a simple String. Once it is referred to it can be treated like the type that it is (i.e. an Asset, PropertyItem, or String).
// When exibit is an asset
// When exhibit is a property item
// When exhibit is a property ID (from foreign system)