Organizing FSM Mobile Files and Report Images by Work Type
For more complex project task configurations, you can place categorized Files views beneath parent tabs for different kinds of work. The historical production configuration used for this example covers damage, new unfinished work, resolved work, Post Rough-in, and Appliance Install. The parent tab organizes the FSM Mobile interface. The category option determines the Files selection.
Use the category-enabled Files definition. For the definition, see Configuring Categorized Files Tabs in FSM Mobile. For this three-group arrangement, merge these parent resources under "routes/mobile". These parents display instructions and have no record-backed article. The customer's full configuration also places custom forms beneath its parents. Those account-specific records and forms are separate from this Files setup.
{
"routes/mobile": {
"damagereportdummy": {
"label": "Damage Report",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record damage with supporting photographs."
}
}
},
"newutasksdummy": {
"label": "New Unfinished Tasks",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record new unfinished work with supporting photographs."
}
}
},
"completeutasksdummy": {
"label": "Unfinished Tasks (to be completed)",
"readonly": true,
"element": {
"instructions": {
"type": "text",
"label": "Note",
"readonly": true,
"value": "Record work resolved from a previous visit."
}
}
}
}
}
Include the following entries in the resources object of each applicable rule at routes/mobile.event.article.projecttask.resources. Use the account's project task conditions. This fragment supplies the three parents and their child Files instances.
{
"array": true,
"parent": [
"damagereportdummy",
"newutasksdummy",
"completeutasksdummy"
],
"files": [
{
"id": "files-1",
"label": "Damage Photographs",
"parent": "damagereportdummy",
"filecategory": "DAMAGE_REPORT"
},
{
"id": "files-2",
"label": "Unfinished Work Photographs",
"parent": "newutasksdummy",
"filecategory": "UNFINISHED_TASK"
},
{
"id": "files-3",
"label": "Resolved Work Photographs",
"parent": "completeutasksdummy",
"filecategory": "RESOLVED_UTASK"
}
]
}
The resources files-1, files-2, and files-3 reuse the supplied files definition. For example, entering Cracked panel beneath Damage Photographs stores [DAMAGE_REPORT] Cracked panel before the capture metadata. The other children use their own prefixes. File upload and attachment still use the current event. The parent resource in FSM Mobile doesn't become the native attachment destination.
The following table lists the additional category groups.
|
Category |
Parent Resource |
Purpose |
|---|---|---|
|
|
|
Photographs beneath the account's Post Rough-in custom-record resource. |
|
|
|
Photographs beneath the Appliance Install grouping resource. |
Those additional parents must be defined before adding their child instances. The Post Rough-in parent requires its account-specific record, fields, and form. A category option doesn't supply them.
Selecting Categorized Files for FSM Service Reports
A report doesn't inherit a child Files tab's filter. Its own contents.image search must select the intended event and category, and the XML template must display that data. The following table compares file selection and caption data for the report definitions in this example.
|
Historical Report |
Additional File Selection |
Caption Data |
|---|---|---|
|
Damage Report |
Description contains |
User description with the category prefix removed. |
|
Unfinished Task Report |
Description contains |
Description with capture metadata removed. The category remains. |
|
Underground Report |
No category restriction. |
User description with the category prefix removed. |
|
Appliance Report |
No category restriction in the standard version. The restricted version selects |
User description with the category prefix removed. |
The corresponding XML templates iterate the image collection and use img.url for the image and img.userdescription for its caption. Their forms, report definitions, and email rules are account customizations.
To apply the damage-photo selection to the existing standard Project Task service report, merge the following fragment. The fragment retains the report's inherited image address mapping and XML template. It restricts the search to the selected project task's upload folders and supported image types, and adds the category condition. Its description mapping removes the category prefix because the standard XML uses img.description for captions.
{
"notification": {
"projectTaskEmail": {
"servicereport": {
"attachments": {
"servicereport": {
"contents": {
"image": {
"filters": [
[
"formulatext:case when {folder} like 'projecttask-${ projecttask.id }-%-%' then 'T' else 'F' end",
"is",
"T"
],
"and",
[
"filetype",
"anyof",
[
"BMPIMAGE",
"GIFIMAGE",
"JPGIMAGE",
"PJPGIMAGE",
"PNGIMAGE",
"TIFFIMAGE"
]
],
"and",
[
"description",
"contains",
"[DAMAGE_REPORT] "
]
],
"map": {
"description": "formulatext:regexp_replace(regexp_replace({description}, '[\\r\\n]*{[^}]*}$', ''), '^\\[[^\\]]*\\] ', '')"
}
}
}
}
}
}
}
}
}
This changes the image collection of the existing service report. The report's folder match has a wider employee scope than the FSM Mobile example. It can therefore include photographs uploaded by other employees for that project task. It leaves the report's other data, email recipients, and sending rules inherited. This configuration doesn't create the separate Damage Report form or PDF described in this example.
For information about configuring a separately named report, see Selecting a Custom Report Template and Supplying Data to FSM Service Report Templates. For information about selecting and sending that report, see FSM Notification Configuration.