Solved

Migrating to NAC and need to reproduce task buttons on Nintex forms

  • 7 December 2023
  • 2 replies
  • 90 views
J
Badge +3

We’re at the beginning of our journey migrating to NAC. There are a couple sticking points. Including one that was made by a consultant years ago. While I’m a developer, I’m not a JavaScript guru. So I’m having trouble transposing things over and while I can handle small chunks, putting it all together in a secure, and functional manner is eluding me. 

It also doesn’t help that now that we’ll be going outside SharePoint more, some of this seems like it’ll require more complexity. For example, authentication will require more than just referencing the logged in user. 

To start, each classic form has approve/reject, JavaScript calling, buttons that only appear for the current approver. And a reference to the task list associated with the form/SP list. 

Those open up a modal window that passes along approve or reject, along with any comments (comments I’m pretty sure won’t even be possible, but that’s a future problem). Where it’s passed to? A click function associated with the modal’s submit button and initialized on “document ready.” 

That click grabs the current list ID and item ID from the URL (using another function for parsing). And then passes all 4 items into the main “updateTaskItem” method. 

updateTaskItem first sets up a SP ClientContext. Then grabs the relevant task list, current user, etc. Then queries (executeQueryAsync) the task list (CAMLQuery) for anything matching the current user, “Not Started” status, etc. And finally executes another [...]queryAsync to update the task. And finally call one of two separate functions depending on whether is succeeded or failed.

I assume the old consultant who’s long gone didn’t make this up from out of nowhere. But I also haven’t seen anything like it in my searches. And now I have to convert it to work with NAC… 

Any help, tutorials, libraries, guidance, etc. would be greatly appreciated. 

icon

Best answer by JakeHarvey 27 December 2023, 22:22

View original

2 replies

J
Badge +3

I’ve made some progress, but might have hit an impossible snag. 

The original JavaScript used, `currentListID, currentItemID, outcome, comments` in its function. The latter two are obviously the info to pass back to the task. But the first portion of the script uses the assignee, the status being incomplete, and those two variables to filter things down more. Three of those four are listed in the API v2. But the item ID (of the list item) associated seems to be missing. So right now, if a user has multiple approvals waiting on them for the same list, they’ll all come back, instead of just 1. 

Even with this is on the form that they’re interacting with the buttons. I’m not sure there’s enough info even coming back from the response. The form wouldn’t know which `workfowInstanceId` that’s associated. 

Please tell me there’s another way besides adding more data to the SharePoint list. I’m already looking to add extra columns to deal with missing things from the NAC workflows themselves. 

J
Badge +3

Luckily I was pointed to the missing piece. It’s a bit of a roundabout situation, multiple API calls to get all the parts. Setting a custom Instance name and the Instances endpoint allowed me to find the active workflow id. And that plus the current user, and current list name allowed for filtering down to the current active task.

Now there are plenty of other things to work out but this was one off the list.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings