Agent Workspace Refresh after Button Click: "UI Action still visible"

[Simon Ohle]

Hey community,

in the Agent Workspace for Change, when clicking the (customized) "Request Approval" button it should set the CHG to a specific state and then reload.

The UI Actions are based on the state of the CHG. Even though the state changed the UI Action "Request Approval" is still visible.

It disappears when I manually reload. 

We can activiely see the reload from the UI Action via "location.reload()", but apparently it reloads too soon, so the UI action visibility gets evaluated before.

1. Is it possible to post-pone the reload, so it saves and then after some time it reloads? (not a nice solution)

2. Is it possible to only reload once its completly saved?

This is the "Workspace Client Script".

function onClick(g_form) {
	
	var ga = new GlideAjax("ChangeRequestStateHandlerAjax");
	ga.addParam("sysparm_name", 'getNextStateValues');
	ga.addParam("sysparm_change_sys_id", g_form.getUniqueValue());
	ga.addParam("sysparm_change_type", g_form.getValue('type'));
	ga.getXMLAnswer(stateValues); 
}

function stateValues(answer){
	
	var returnedStates = JSON.parse(answer);
	g_form.setValue('state', returnedStates[0]);
	g_form.save();
	location.reload();
       //g_form.reload() has not work either
}

Thans for any help.

Cheers,
Simon

[karim9]

i faced a similar situation recently where we need to refresh the agent workspace form as it is not updating fields automatically after interaction closure.

You can create a client script on the target table (e.g., Interaction in my case) 

Client script will be on-change & field selected was closed (date/time) & make sure to uncheck global checkbox and type workspace (to make it work on only agent workspace)

If(newValue !=""){

g_form.reload()

}

Note: Also make sure closed date is available on form else code will not work. Later you can hide closed field with a UI policy.

So whenever closed date is filled the form will auto-refresh. 

[Simon Ohle · Accepted solution]

Thank you for your suggestion. 

The problem here was that it was actually a second UI Action, that had the same name, evaluated to true for a short amount of time. Re-thinking the evaluation of the second UI action led to us being able to fix the problem.