How to remove duplicates on-the-fly from cascading dropdown lists - Nintex Form - JavaScript


Badge +1

First I’d like to say I’ve only been working with NinTex workflows for about two weeks now between my other tasks, I’ve no Java/JavaScript programming knowledge, and I have yet to get a handle on how all of the Nintex/SharePoint pieces work together. I’ve created and published one Nintex form, list, and workflow and it seems to be working and sending notifications properly. The only problem I’m having with it is…

I have a JavaScript snippet (that I got from this forum) located in my Nintex Forms ‘Settings/Custom JavaScript’ that runs on form load and removes duplicates from lookup fields where I have ‘duplicates’ referenced in the form control’s ‘Control Settings – List Lookup/Formatting/Control CSS class’. The JavaScript function works great.

Here’s the script:

NWF.FormFiller.Events.RegisterAfterReady(function(){
     NWF$('.duplicates').each(function(){Update(this.id);});
});
function Update(control){
     var usednames={};
     NWF$("select[id="+control+"]>option").each(function(){
          if(usednames[this.text]){$(this).remove();}
          else{usednames[this.text]=this.value;}
     });
}

On the Nintex (Classic) Form I have cascading lookup controls that only populate after a selection is made in the previous control. When a user selects lkup_Dept then lkup_Div populates based on the lkup_Dept selection, and so on down the list. Without input from the previous lookup controls, the lower controls remain blank.

lkup_Dept

lkup_Div

lkup_Branch

lkup_Section

Because lkup_Dept is the only control that is set to populate on form load, the JavaScript control ‘duplicates’ only runs on the lkup_Dept control. You know where I’m going with this.

I’d like to setup a JavaScript EventListener that runs the Update function on the form’s next-in-line lookup control whenever a selection is made or changed to the previous control.

Thanks for your help.


5 replies

Userlevel 5
Badge +14

why do you have duplites there?

I'd suggest to think of proper design instead of removing duplicates...

 

imagine a hierachy scenario:

dptA  with ID:1

    div1

    div2

dptA with ID:2

    div3

    div4

 

 

 

first isuue - how will you decide which of two dpts with the same name to delete? one with ID:1 or one with ID:2?

 

second issue - if you eg. delete a dpt with ID:2 you'll then never be able to select divs div3 and div4 since they are related to dptA with ID:2 (and all the subsequent subtree...)

 

 

Badge +1

They receive monthly a multi-column position listing that's imported as a sharepoint list. Each lookup control keys off of a column in the provided list. The columns naturally contain duplicates in order to relate each row down to the section level. I considered creating multiple lists off of the original but for ease of management they only want to work with the one unmolested list.

I had consdered the ID issue too, but because I'm keying off of the text of the field, not the ID, the ID isn't relevent. By keying off of the text the cascade produces additional unrelated selections if they exist, rather than losing related selections. I've discussed this with them and they say they aren't concerned as know which ones are valid.

So I'm back to the JavaScript solution and removing duplicates after the control loads unless there's a simpler way.

Userlevel 5
Badge +14

structured parent-child relations would save you from several problems, but as you wish....

 

 

well, there is not any event that would be fired and could be captured when subordinated lookup gets populated.

the only possible approch (I'm aware of) is to capture a change event on superordinated lookup, wait for some reasonable delay and apply action (deduplicate) on subordinated lookup

Badge +1

Just a followup...

I got frustrated and didn't have much time to play with this anyway so I wrote a routine that parses the original list and removes duplicates outside of SharePoint and then it imports the four created lists. I then attached the form's lookup fields to the separate lists and it works fine. I'm not fully happy with the solution; I wanted to stay within the confines of the Nintex flow but it seems there's no easy built-in way to stop duplicates from displaying in the dropdowns. I'm also a nube to Nintex so that doesn't help either. Thanks for your input. :)

Userlevel 5
Badge +14

do not take it as a frustration or unhappines. take it as a first learning :)

you're heading to a solution I've suggested at the beginning....

 

there are few more "learnings ahead of you, considering what did you started from

 

Reply