Using JavaScript to Create a New Child Item Popup Form

One of the ways to allow your users to create a child item relationship with Nintex in SharePoint is to use JavaScript to add new child items in a popup dialog.

The New Visit popup dialog lets a user add new child list items related to the parent list item

 

In this example, I’ll use a Patients list and a Visits list. Each patient can have multiple doctor visits. If we refer to this as a one-to-many relationship, the Patients list is the “one” and the Visits list is the “many.” If we refer to this as a parent/child relationship, the Patients list is the “parent” and the Visits list is the “child.”

 

The Patients list with columns PatientID, LastName, FirstName, and DateOfBirth

 

The PatientID column on the parent list is what I call a Legacy ID and can be generated by a workflow after the new item is saved. A Legacy ID almost always generated by incorporating the built-in SharePoint ID. In this example, I’ve defined the PatientID as last name, first initial, a numeric date of birth, and the SharePoint ID. The specific syntax for this example is not important, but it is important to understand that when the SharePoint ID is used as part of an identifier there is a minor limitation I’ll describe later in this post.

 

This is the Patients form created as a Nintex responsive form

 

Notice that the Patients form includes a table of the multiple visits for this patient. This is the relationship we are going to connect in this example, using an Add New Visit button and a popup dialog to add each visit. Notice that the TekDog Productivity Controls also offer the same option to have a Add New button and a subform control to display the data, however, unlike this example, the TekDog Productivity Controls do not require any JavaScript or other formulas.

In this case, in lieu of the TekDog Subform control, the visits data is displayed using Calculated Value controls as documented in the TekDog blog post, “Using the Nintex Calculated Value Control to Display Child Line Items.”

The JavaScript I will use in this example will read the PatientID value from the Patients form and call a function to show the new item form for the Visits list. The PatientID will be passed to the Visits form in the URL for the new item popup dialog. The PatientID will then be retrieved in the Visits form using a Nintex runtime function.

The Visits list has columns about the details of the specific visit, like the date and time and the location of the appointment. The key to maintaining the relationship with the Patients parent list is the PatientID column in the Visits list. The multiple visits of one patient are represented by multiple list items in the Visits list that each have the same PatientID of the patient in the Patients list. The PatientID values in the Visits list will be entered automatically by the JavaScript and Nintex runtime function used in this post.

 

The Visits list includes the columns DateOfVisit, Location, ChiefComplaint, and PatientID

 

The Visits form should be constructed in the Nintex form designer as usual before we add the JavaScript and Nintex runtime function to the forms.

The Visits form as it would look as a normal Nintex form that isn’t a popup

 

How can we create a JavaScript-enabled button in Nintex responsive forms? Last I checked, the official statement from Nintex is that JavaScript can’t be used in responsive forms. But you can.

On your child form, put a label somewhere. It’s going to be empty except for some JavaScript. Click in the body of the label’s text setting, and click the Edit Source button on the Format Text ribbon. This is where I copied the following HTML and JavaScript:

 

<script type="text/javascript">
function addNewVisitPopup() {
      let patientId = NWF$('div[data-controlName=PatientID] input').val();

      let options = {
         title: "New Visit",
         width: 400,
         height: 600,
         url: "/Lists/Visits/NewForm.aspx?PatientID=" + patientId };

      SP.UI.ModalDialog.showModalDialog(options);
}
</script>

<input type="button" onclick="addNewVisitPopup();" value="Add New Visit​" />​

 

The JavaScript embedded in the HTML defines a function named addNewVisitPopup(). In the first line of the function, Nintex’s alias for jQuery, NWF$, is used to retrieve the PatientID value from the textbox control on the form. The jQuery selector works because the Nintex control for the PatientID is actually an HTML input element inside a div element with the attribute data-controlName set to PatientID. Note that the PatientID control in the Patients form must be named PatientID in order for the jQuery selector to find it in this example.

 

Using a Nintex Label control to insert an HTML button and JavaScript into the Patients form

 

 HTML and JavaScript added to the Nintex Label control with the Edit Source option on the ribbon for the label

 

The rest of the addNewVisitPopup() function sets up the use of SharePoint’s showModalDialog() function. The showModalDialog() function is part of the SharePoint API and is used throughout SharePoint when it needs to show a popup to the user. The showModalDialog() function requires an option parameter that includes information about how you want the popup to look and most importantly, the URL for the popup form.

I referred to the following Microsoft article when using the showModalDialog() function for this post.

“SP.UI.ModalDialog.showModalDialog(options) Method,” Microsoft, 7/24/2014, retrieved 5/27/2022
https://docs.microsoft.com/en-us/previous-versions/office/developer/sharepoint-2010/ff410058(v=office.14)

In this case, what we want to use for the popup URL is the new item URL for the Visits form. To get this URL, I click New Item on the Visits list and copy the URL from the address bar of my browser. However, the complete URL has way more information tacked on to it than we really need.

My complete URL was:

http://tekdogdev13.tekdog.local/Lists/Visits/NewForm.aspx?Source=http%3A%2F%2Ftekdogdev13%2Etekdog%2Elocal%2FLists%2FVisits%
2FAllItems%2Easpx%3FPatientID%3DWilsonS%5F20060103%2D1&RootFolder=

 

When you copy a URL from SharePoint this way, usually there will be a Source parameter that is used for navigating with the back button of your browser. Since this is a popup dialog, we don’t need or want the back button functionality. So everything after the question mark can be removed.

http://tekdogdev13.tekdog.local/Lists/Visits/NewForm.aspx?

 

Furthermore, since the Visits form is on the same SharePoint site as the Patients form, we can use a relative URL without the absolute domain part of the URL.

/Lists/Visits/NewForm.aspx?

 

Finally, we need to add the PatientID retrieved from the Patients form to be appended to the rest of the URL option. After the JavaScript adds the patientId variable to the URL, the complete URL for the popup will be as follows for this patient.

/Lists/Visits/NewForm.aspx?PatientID=WilsonS_20060301-1

 

Lastly, the addNewVisitPopup() function makes the call to showModelDialog() with the given options. The last line of the HTML in the Nintex label control is an input element that defines the button that will be clicked to activate the addNewVisitPopup() function and display the popup.

When Nintex loads the Visits form for the popup dialog, the PatientID in the URL can be retrieved and placed in the PatientID control for the Visits list. This will tie the Visits list item to the correct Patients list item. To retrieve the PatientID from the URL, we can use the Nintex runtime function GetQueryString().

 

The PatientID control in the Visits form uses the GetQueryString() runtime function to retrieve the PatientID from the URL

 

To use the GetQueryString() function, open the Control Settings for the PatientID control. For the Default value, click the Insert Reference icon, click the Inline Functions tab, and find GetQueryString. Double-click GetQueryString to insert it into the text box at the bottom. The GetQueryString runtime function requires one parameter, the key name to retrieve. In this case our key is PatientID and should be put in quotes between the parentheses. Be careful of your syntax as it is case-sensitive.

 

GetQueryString configured in the Insert Reference dialog

 

Once you have the GetQueryString() runtime function properly configured, you can publish the form and test it on its own without the Patients form by constructing the correct NewForm URL with a test PatientID after the question mark as in the example above. If it’s working correctly your test value will appear in the control on the Nintex new form. Note that if the Control Mode is set to Display in the Advance section for the text box, Nintex won’t save the default value from the URL. If you don’t want the user to edit the value you might have to find a workaround for this, but this solution is probably for another blog post (possible solution hints: hide the control behind something, use CSS to prevent clicks or tabs into the control, use JavaScript to hide the control, or JavaScript to trigger the change event to get Nintex think the user did something).

That’s it! If you get yours working, you should have an Add New button and a popup working as shown at the top of this article.

Note that in this example I intentionally used a generated Legacy ID (Patient ID) that isn’t available until after the list item is being saved by SharePoint. Before SharePoint saves the list item, the SharePoint ID is not available, and the SharePoint ID is part of the Legacy ID. Therefore, you will not have the correct PatientID at the moment a user is creating a new patient with the Patients new form. This means that without the correct ID, the popup will not be able to relate the Visits list item to the correct Patients list item. This is a common situation when creating data relationships in SharePoint. So the solution described in this post will only work for an existing Patients list item and not one that is in the process of being created. The user will have to create the patient first, and then go back to edit the patient in Edit Form mode in order to add new visits.

A good solution to this issue is to use a randomly generated GUID on the parent form as the key identifier of the parent list item, and pass that GUID to the child form in the URL instead of passing the not-yet-generated legacy ID. This is why the TekDog Productivity Controls use GUIDs to relate list items. The use of GUID for data relationship in SharePoint list will be a topic for another article.

.