Vancouver upgrade --- set assigned to/assignment group

[jxsaxton421]

When a user has a security incident response task, and they update the assigned to/assignment group fields, the form saves but the assigned to and assignment group field are blank and the red mandatory asterisk is visible on the screen. However, the ticket moves to assigned even though it's not clear who's assigned the ticket. 

I was thinking it was a business rule - Build scratchpad & display info messages - on the Service Order Task table that didn't get updated, but it seems to be working in Rel just fine. Our vancouver upgrade introduced a couple updates to that business rule including a call to this 

// populate scratchpad value for onsite configuration

var fsmOnsiteUtil = new global.FSMOnsiteUtil();    

g_scratchpad.enableOnsite = fsmOnsiteUtil.isOnsiteEnabled('wm_task');

But FSMOnsiteUtil is not a script include in our instance or in our preupgrade instance. Would anyone know where else to look to see where this should be? 

[Martin Dewit]

Check to see if there were any changes to this Client Script, "Update Assigned to (Assign Group change)" for Service Order Task [sm_task]. This is what clears the assigned to when assignment group changes. FSM (Field service management) seems to be used in this client script as well. 

[jxsaxton421 · Accepted solution]

Yes, from NOW support there seems to be a breaking change in Vancouver that broke a workaround. 
When my company implemented Security Operations, they asked for any IT group to be assigned response tasks (even though reading the documentation I don't think that's how it's setup OOTB). So, the implementation developers modified the assignment group override so that those groups show up in the list and the form could be saved with those assignment groups/assigned to with no issue. 

In Vancouver, there was an update to a black boxed script include and now when the task is saved -- ServiceNow is enforcing looking at the application (Security Operations, CSM, HR) configuration record for the task work group type. If it doesn't validate it, it clears it out.

In the security operations case, the response work group type is "response_task". Only security groups had that response task and not any of the other IT groups we have in the company because the workaround of only messing with the assignment group override worked fine until Vancouver. 
The solution was to add the response_task group type to all the groups we needed and the validation works correctly now.