Request Offering: Request On Behalf Of logic

Aaron_Boock

I'd like to hide a user prompt in my request offerings unless a user is input into the Create Request On Behalf Of prompt. 

I assume javascript can show/hide my request offering user prompt when the Create Request On Behalf Of prompt changes (add/remove user)?

Aaron_Boock

Thank you to all the contributors for the ideas and leads.

Brett_Moffett

To do this sort of dynamic Request Offering I would suggest using an Advanced Request Offering.

You can get more detail here: https://support.cireson.com/KnowledgeBase/View/1270#/

Aaron_Boock

I added a True/False to permit users to indicate if they are submitting on behalf of another, it is redundant after already specifying a user to create on behalf of. 

I would like to know how to use some javascript to hide a user prompt within the offering (if possible) unless requester specifies a user in the Create Request on Behalf prompt. 

Brett_Moffett

So you are using an Advance Request Offering but the "On behalf of another user" is not a field that shows up in the wizard? 
Is that right?
I've not tested it but from memory you can't see that field from the ARO wizard.    

Hmmmm
Javascript could do it, but the field you are hiding could not be a "Required" field as it would see that field and not save the form, but the user would never see it.
The JS would be very specific to that one RO.... Not sure if someone has an example they can share?

Aaron_Boock

Yes, that's right.  I want to drive logic on whether Create Request On Behalf Of has a user value.  If it does, show a prompt in my request offering.  If it does not, hide the same prompt in my request offering.  This would mean it would hide on load of the request offering and hide when a user is provided for Create Request On Behalf Of.

seth_coussens

To directly answer your question, we don't current 'support' editing the RO pages with javascript via the custom space or any other method. That being said, if it's in the custom.js file it's easily removed which would bring you back under support whenever needed, so it is possible to manipulate the RO page it's just that support won't be able to help you out with any issues.

For this particular functionality, I would suggest targeting very specific RO pages for this behavior if possible, so you can tightly control which RO this functionality appears on. You can do this by having a JS function that looks for the URL of the RO you want to apply this to (this could be one or more, set in an array). Something like this would work for that (this just shows a few ways to use that functionality):

<br><div>$(document).ready(function (){
	//click the show activities by default
	var href = window.location.href;
	if(href.indexOf("62f452d5-66b5-429b-b2b1-b32d5562092b") > -1 || href.indexOf('cca5abda-6803-4833-accd-d59a43e2d2cf') > -1){
		console.log("I'm on the AllWorkItems Page!");
		setTimeout(function (){
			$('#showActivitiesInGrid[value=false]').prev('input[type=checkbox]').trigger('click');
		}, 1000);
	};
	//hide null values for configuration items
	if(href.indexOf("03a1c11e-47f1-470c-b115-f34a1693de59") > -1){
		console.log("I'm on the CI Search Page!");
		setTimeout(function (){
			$('table.k-selectable').on('click', function(e){
				console.log("You clicked a cell!");
				setTimeout(function (){
					$('#objectInfo tbody td').each(function(index){
						var ele = $(this);
						console.log("Hiding null elements...");
						var par = ele.parent('tr');
						if(ele.text() === 'null')
							par.hide();
					});
				}, 250);
			});
		}, 1000);
	}
	//set request offering grids to 5 items per page
	if(href.indexOf("ServiceCatalog/RequestOffering") > -1){
		console.log("I'm setting the grids to 5 items per page.");
		$('[data-role=grid]').each(function (index){
   			$(this).data('kendoGrid').dataSource.pageSize(5);
		});
	}
});<br></div>

Those examples apply different functionality to different pages around the portal just an an example. From here you could then attach functions to events in the RO page (such as setting the requested by user) and then show or hide fields based on those events.

Is this what you had in mind?

Aaron_Boock

You pretty much nailed it Seth.  Only it would likely be something a majority of my ROs would use.

I have high demand in my environment to allow the submitter (created by user) to indicate which user gets the ongoing notifications.

I have extended the IR/SR class to add a UserToNotify property.  I then provide a simple list to allow submitter to choose who gets notified: Affected User, Submitter (created by user), or Both.  The selection from this simple list populates the UserToNotify propery.  I have SCSM subscriptions for each possible UserToNotify value

What I truly desire is that whenever a user is input to the Create Request On Behalf Of prompt, the UserToNotify simple list is then displayed on the RO form.  Plus, when a user is cleared, it should be hidden.

seth_coussens

Aaron_Boock said:

You pretty much nailed it Seth.  Only it would likely be something a majority of my ROs would use.

I have high demand in my environment to allow the submitter (created by user) to indicate which user gets the ongoing notifications.

I have extended the IR/SR class to add a UserToNotify property.  I then provide a simple list to allow submitter to choose who gets notified: Affected User, Submitter (created by user), or Both.  The selection from this simple list populates the UserToNotify propery.  I have SCSM subscriptions for each possible UserToNotify value

What I truly desire is that whenever a user is input to the Create Request On Behalf Of prompt, the UserToNotify simple list is then displayed on the RO form.  Plus, when a user is cleared, it should be hidden.

This would be a matter of having the property in the RO already (which is sounds like you do) and then looking in the HTML to find some factor that identifies this field. Once you do that you can do what I suggested above by placing a change event on the On Behalf of prompt that then shows or hides the that field in the RO.

Obviously, you can't use the ARO to do this because the On Behalf Of field is not technically a part of the RO form, but something we add on.

Aaron_Boock

I've got page-load logic, but not sure what to use when the AffectedUserName.value changes.

Note: I'm testing by hiding the Filter item within query results prompt.

//RO hide Filter on load if no create request on behalf of user set
$(document).ready(function (){
 if(window.location.href.indexOf("ServiceCatalog/RequestOffering") > -1){
  console.log("I'm on a Request Offering page.");
  if(AffectedUserName.value == ""){
   console.log("No affected user");
   $('input[placeholder="Filter"]').parent().hide();
  }
 }
});

Brett_Moffett

You would have to use an Java script OnExit event of the control.

Aaron_Boock

Thank you to all the contributors for the ideas and leads.