Unable to Edit "source_request" UI page or call a Copy of the UI page in the OOB UI action "Source Request"

manita_anand
Giga Expert

Need a workaround to either Edit existing UI Page  or Copy UI Page "Source_Request"  and make highlighted checkbox = true.

The UI page is called in the UI Action "Source Request" with code as below :

 

function openSourceRequestPage() {
var gr = new GlideRecord("sc_task");
gr.get(g_form.getUniqueValue());

var url = new GlideURL('$source_request.do');  // without '$' sign the code change can be seen but view is not same as below
url.addParam('sysparm_stack', 'sc_task.do?sys_id='+gr.sys_id);
url.addParam('sysparm_req_sysid', gr.parent);
url.addParam('sysparm_sc_task',gr.sys_id);
url.addParam('sysparm_nostack', 'true');
window.location.href = url.getURL();
}

 

find_real_file.png

1 ACCEPTED SOLUTION

Hi..apologies for the late reply.

 

We went through lot of trial and error in getting all of this to work. A lot of custom functionality was added (being able to save and retrieve state, vendor /model defaults, etc) which contains proprietary information so unfortunately I cant share out the code but Ill share what I can. 

Keeping to the OOB functionality was not a requirement so the main goal was to get either Transfer Orders or Purchase Orders created based on the choices selected by the Procurement team. The system would then handle the rest as intended. 

The OOB system functions we were after are contained in the ProcSourceRequestManager Script Include. From there we simply extended the class with a custom script include and then we added new, as well as, overwrote OOB functionality. Keep in mind the main purpose of the OOB Source Request page is to either create a Purchase or a Transfer Order. One other function is to handle entitlements for software requests.

The widget loads the request data using the following server script:

(function() {
	/* populate the 'data' object */
	var transaction = new GlideTransaction.get();  
	var request = transaction.getRequest();  
	var psrm = new Custom_ProcSourceRequestManager(request);

	//on load, check if there is any saved data
	if(!input){
		data.request = psrm.getREQData();
		data.request.saved = psrm.saveFound(data.request.req_sys_id);
		data.request.sc_task_sys_id = $sp.getParameter("sysparm_sc_task");
		//console.log(data);
	}	

	//save function
	if(input.action == "save") {
		data.num = psrm.saveSourceItems(input.data);
	}

	//load default data function 
	//get all the RITM info, the defaults, and the associated vendors/stockrooms/licenses for the given RITM
	if(input.action == "loadDefault") {
		var req_items = psrm.getSCRequestItems();
		data.items = psrm.buildDataToSubmit(req_items);
	//	console.log(data.items);
	}

	//load saved data function
	//find all the data for a given saved file
	if(input.action == "loadSaved") {
		data.items = psrm.getSaveData(input.number, input.req_sys_id);
	}

	if(input.action == "submit") {
		data.response = JSON.parse(psrm.processRequest(input.sc_task_sys_id, input.req_sys_id, input.data));
	}

})();

 

A UI Action on the Procurement Task directs the user to the new form with passed parameters:

function Custom_openSourceRequestPage() {
	var gr = new GlideRecord("sc_task");
        gr.get(g_form.getUniqueValue());
	
	var url = new GlideURL('pc/?id=custom_source_request');
	url.addParam('sysparm_stack', 'sc_task.do?sys_id='+gr.sys_id);
	url.addParam('sysparm_req_sysid', gr.parent);
	url.addParam('sysparm_scReq', gr.parent);
	url.addParam('sysparm_sc_task',gr.sys_id);
	url.addParam('sysparm_scReqTask',gr.sys_id);
	url.addParam('sysparm_nostack', 'true');
	window.location.href = url.getURL();
}

 

When the new portal Source Request page loads the following is displayed:

find_real_file.png

Hopefully this helps point you in the right direction.

 

--David

View solution in original post

9 REPLIES 9

DScroggins
Kilo Sage

Hello,

Unfortunately that page is 'black boxed' and cannot be edited or copied. The code is even hidden from normal view. We had the same requirement to make a few minor modifications to the sourcing request page and the only solution was to rebuild the front end functionality using a portal page and widget. The widget utilizes a custom script include which extends the ProcSourceRequestManager class. We then updated the Source UI Action to point to the new portal solution.

Thanks David!

The solution you mentioned, did that cause any issues while upgrading the instance? 

 

No there have been no issues with upgrades as we extended the OOB script include ProcSourceRequestManager as opposed to modifying the OOB code. As for the portal page and widget those were also custom so no issues have been identified when upgrading. We have gone through two family upgrades since this solution was developed. 

thanks David, this was so helpful.

building widget is not a problem, i did that but we have no reference for server level code and client controller functions and they should work exactly the way it works in out of box.

th doubt in my mind is when we dont know how code is working at backend, how are we sure we built it exactly the way it is in OOB ?

Thanks in Advance!