Fixed templatizing of Forms and Workflows

[MikeTschudi]

• The naming of Workflow URLs in the code was confusing to me. Now standardized to
  • workflowBaseUrl is the base path for queries to the Workflow server. For example, to test if Workflow is authorized, one calls const url = `${workflowBaseUrl}/checkStatus`;. In addition, the templatized symbol for a Workflow URL is {{workflowBaseUrl}} to be consistent.
  • workflowServerUrl is a URL returned by AGO or Enterprise helper services. It is converted into a workflowBaseUrl in one of two ways:
    • AGO: `${workflowServerUrl}/${orgId}`
    • Enterprise: ${workflowServerUrl}/workflow
• A Form's data zip file contains the following files which are templatized: *.info, *.itemInfo, *.json, *.webform, *.xml. For each, the contents of the templateDictionary are used to templatize
  • the item id references
  • the feature service url references
  • portal base url references
  • workflow manager base url references
• A new set of entries is made into the templateDictionary: one for each item added to a Solution during creation. These entries consist of the item id suffixed with "_type" so that they don't stomp on entries with just the item id. These entries contain the item type and url. For non-Feature Services, the URL is ignored and the id is simply templatized in the Form. For Feature Services, the URL is used to find a templateDictionary entry matching the URL, which is then used for the templatization.
• Function argument order was rearranged for Forms to be consistent.
• Function getWorkflowManagerUrlRoot in the common package was removed because it contributed to the Workflow URL confusion. Its capabilities have been incorporated into function getWorkflowBaseURL.

The changes are breaking for the deployment app because of function argument changes.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (586b9ca) to head (91dc059).

Additional details and impacted files

@@            Coverage Diff            @@
##           develop     #1468   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          150       149    -1     
  Lines         8399      8394    -5     
  Branches      1951      1950    -1     
=========================================
- Hits          8399      8394    -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chris-fox]

• A new set of entries is made into the templateDictionary: one for each item added to a Solution during creation. These entries consist of the item id suffixed with "_type" so that they don't stomp on entries with just the item id. These entries contain the item type and url. For non-Feature Services, the URL is ignored and the id is simply templatized in the Form. For Feature Services, the URL is used to find a templateDictionary entry matching the URL, which is then used for the templatization.

@MikeTschudi, i understood most of what was described here with the exception of above. Could you elaborate on this?

[MikeTschudi]

I needed to have a list of item ids that were in the Solution being created so that I could templatize only those ids in Form data (rather than templatizing everything that matches an ArcGIS id pattern). I also needed to know the item type so that I could handle Feature Service URLs (vs. simply templatizing ids).

We currently store some ids in the dictionary, but not all. And the value is an id; replacing it with a structure that included the type and, for Feature Services, the URL broke things in more places than it was worth.

Instead, for each item added to a Solution, I create a dictionary entry in the form <id>_type that contains a small structure: the item's type and its URL. (The URL is only meaningful for Feature Services.)

During Form post-processing, which occurs after all items have been added to the Solution, I extract the <id>_type entries. For non-Feature Services, I templatize the id in the Form data. For Feature Services, I look up the URL in the dictionary, and then replace all occurrences of that URL with its dictionary value in the Form data.

[chris-fox]

Thanks Mike, I just want to make sure we are not doing something too special for Forms. I believe we have and use this kind of logic on a lot of other item types. For example, I know in Web Maps and Dashboards we do a post process to find references to item ids and feature service urls that might in the data json, but were not explicitly found in our logic to search for dependencies. For example, references in arcade expressions.

My point is this is good logic for all item types, a post process that handles finding item id or feature service url references in items that are apart of the same solution. Our auto discovering of dependencies logic is nice and works well for a lot of item types, but items continue to get more complex and references between items get harder to always account for. This post process logic has seemed to be very safe and reliable for finding and swapping out these references with variables.