We’ve had a large number of requests for this sort of functionality, but if you aren’t one of the customers making this request then you may not entirely understand what we are talking about here. What I mean by dynamic forms, is that the SR/IR/CR form changes the fields it shows and the ordering of the fields as you see fit based on the template id of the WorkItem. Let’t look at a few scenarios where this would be useful.

One common scenario is when you have a particular Request Offering in the Service Catalog that serves a very particular purpose, most commonly something like a project request or a new user access request. In either of these scenarios the general information you might be requesting from the user is not going to fit readily into the standard fields for the service request.

With this in mind you are left with a few options. You can extend the service request class to contain additional fields to hold this information and name each field according to the information it will contain, or you can extend the workitem with a generic set of fields to contain the information from both types of request (we consider this best practice), or you can try and fit the information into the default fields. For this article we are going to work with what we consider to be best practice.

Now we have a set of default extended properties that we are storing the information in, but this doesn’t help the analyst all that much when they go to view the ticket. By default in the Cireson Portal we don’t show the extended properties. You have to surface these properties by customizing the forms .js file and placing the customized version in the customspace folder. I’m going to show you how to do that first.

Cireson Portal WorkItem Form Customization

We’ll start out by discussing what happens in the portal in terms of the workitem forms. In it’s most basic terms, we are using a template that is coded in JSON and then using that to determine the look, feel, and data bindings of the workitem form in the portal.

Looking a little deeper into the process, we are defining in the template the variable we wish to bind to, and the type of control that we want to use to display that data. In order to accomplish this, we bring in all of the workitems properties by making a call to the SCSM SDK when we load the form. We then look at the data model that is returned and bind the form to the data model using the template, and thus the various controls we defined.

After all of that we end up with this:

As you can see from this form we don’t have any extensions, but if we use the developer tools in the browser (F12) we can see that the extensions are there in the data model:

Knowing that the data exists in the model, we just need to know how to drag it out and display it in the form. This is where the information above becomes important. We are going to modify the workitem form template so that the portal displays whatever data properties from the model that we desire, with whatever controls fit, and with whatever name we want the data to be represented as.

In this example we are going to add a project TAB to our SR form (which can be seen in the image above). In order to do this, we need to copy the servicerequest.js template from the CiresonPortal\Scripts\Forms\Templates folder to the CiresonPortal\CustomSpace folder. Then we need to edit it:

If you look through the file, the structure is fairly easy to identify with a little help which can be found here for our portal customers:

https://support.cireson.com/KnowledgeBase/View/51#/

As this article is not focused on form customization I’m just going to talk the basics, but the breakdown is something like this…

1. Form name (default for the default form) [object]
   1. tablist (each object in this array constitutes a tab)
      1. name (name of the tab)
      2. content (content of the tab)
         1. customFieldGroupList (contains the header and the rows)
            1. name (header of the subsection)
            2. rows (defines what fields will show in each row)
               1. columnFieldList (contains the definition for each column item)
                  1. datatype (defines each individual form control, this is the key piece that will display our properties)

A few simple details, there is no real limit on the number of rows you can have, but the columns are generally broken up into four separate columns per page. There are a number of datatypes you can use, but we won’t be reviewing those there. Rather we are going to simply focus on what we need to do to bring the property out.

We are going to look at an extension that is a simple text property, but first we are going to create a new TAB. To do this, simply follow the bones of the other tabs layout. Here is a simple example:

 

 /*********/
/** TAB **/
/*********/
{
    name: "Project",
    content: [
        {
            customFieldGroupList: [
                {
                    name: "Project Request Information",
                    rows: [
                        {
                            columnFieldList: [
                                { DataType: "UserPicker", PropertyDisplayName: "AffectedUser", PropertyName: "RequestedWorkItem" },
                            ],
                        },
                        {
                            columnFieldList: [
                                { DataType: "LongString", PropertyDisplayName: "Description", PropertyName: "Description", MinLength: 0, MaxLength: 4000}
                            ],
                        },
                        {
                            columnFieldList: [
                                { DataType: "Enum", PropertyDisplayName: "Urgency", PropertyName: "Urgency", EnumId: 'eb35f771-8b0a-41aa-18fb-0432dfd957c4' },
                                { DataType: "Enum", PropertyDisplayName: "Priority", PropertyName: "Priority", EnumId: 'd55e65ea-fae9-f7db-0937-843bfb1367c0' },
                            ]
                        },
                        {
                            columnFieldList: [
                                { DataType: "Enum", PropertyDisplayName: "SupportGroup", PropertyName: "SupportGroup", EnumId: "23c243f6-9365-d46f-dff2-03826e24d228" },
                                { DataType: "UserPicker", PropertyDisplayName: "AssignedTo", PropertyName: "AssignedWorkItem" },
                            ],
                        },
                    ]
                },
                {
                    name: "ActionLog",
                    type: "actionLog"
                }
            ]
        }]
},

Using the example above we can simply take this and paste it into our file following the code for the GENERAL tab. If you’d like to see the actually code, you’ll find it attached here:

DynamicFormsBlog.zip

Now we have our modified ServiceRequest.js and it should be in our customspace folder. If we refresh our portal service request form (it doesn’t matter what service request you are looking at at this point), you should see the PROJECT tab appear:

Now that we have our PROJECT tab we can select it and see the design we’ve established for the form. This ideally should be the design that contains all the information we want to display for the PROJECT service request type (I’m demonstrating Project Owner below):

With the new tab in place showing the information we want in the way we want, our next step is to display this tab as the default for this type of request, and perhaps even hide the general tab since we won’t be using that information. We will look at how we can do this in our next installment.