Enhance the substituteFields function

[jbates-2]

The current substituteFields capability is useful, but could stand a few improvements. I'm lumping these together, although they wouldn't necessarily need to be implemented at once.

1) Allow the function to trap or ignore missing or incorrect field names. Today, a string that contains text that happens to use the same syntax that substituteFields will cause substituteFields to throw an exception. I would like to see an option that allows the function to ignore these cases and leave the original text as-is. For example, if I have a text field with the contents:  {Creating User}={Created By} would not cause substituteFields to fail if there was no field called "Creating User".

Rather, the result from substituteFields would be: {Creating User}=jsmith

2) Allow the function to have an option to allow recursion. Example:

Field Text1 contains the text: created on {Created Date} which was set by a trigger somewhere. Another possible option for this field would be: last modified on {Modified Date}  The trigger that sets this field determines what the value should be.

Field Text2 contains the text: "{Summary}" of type {Type} and ID {ID} was {Text1}

A subsequent trigger fires to complete the contents of Text2 using field substitution with recursion, to return:

      "This is the summary" of type Defect and ID 123 was created on 2016/06/10 12:18:00 PM

3) Allow the function to allow fields to be substituted from related items (specifically, IBPL), such that I could use a syntax like:

Field Text1 = Release "{Summary}" on Product {Product_IBPL:Summary}

Calling substituteFields would follow the Product_IBPL field to get the value of Summary when creating the output.

Now, putting this all together, you have the ability to create something like this:

Field Text1 contains the text created on {Created Date} and exists on the Product item type

Field Text2 contains the text "{Product_IBPL:Summary}" of type {Product_IBPL:Type} and ID {Product_IBPL:ID} was {Product_IBPL:Text1} and exists on the Release item type, that also contains the Product_IBPL field. Each piece of the puzzle can be created by different processes in the solution, with the last step of the process completing the assembly.

All of this has been created repeatedly in various triggers over the years. In most cases, the triggers are used for email notification, but I have used this in other locations as well. The specific syntax for relationship fields that I've used is a bit different than outlined here, but this is to outline the concept, not provide the full solution.

Other options that are field type-specific include options for things like user fields, where the field could be specified as:  {Assigned User/email} to return the email address of the user, or {Assigned User/userid}, or whatever makes sense. Relationships could add other types of value such as {Related Items/count} which would provide the count of the related items in cases where there is no count or computed field available.