document.getElementsByTagName is not working in scope application

[anshul_jain25]

Hi all,

document.getElementsByTagName is not working in scoped application I have written below code in my ui action, I need to change color of my button to green when I click on it.

please let me know what can be done here

function ResolveCall(){

//if(confirm('Are you sure you want to Resolve Call?')){

  g_form.setReadonly('priority' , false);

  g_form.setMandatory('priority' , true);

  g_form.setReadonly('close_notes' , false);

  g_form.setMandatory('close_notes' , true);

  g_form.setReadOnly('u_process_category' , false);

  g_form.setMandatory('u_process_category' , true);

  g_form.setReadOnly('u_process_subcategory' , false);

  g_form.setMandatory('u_process_subcategory' , true);

  g_form.setReadOnly('u_process_activity' , false);

  g_form.setMandatory('u_process_activity' , true);

  g_form.setValue('u_subject', 'Resolve Call');

// g_form.setReadonly('comments' , true);

  alert('asdasd');

  var items = document.getElementsByTagName('button');

alert(items+'asd');

for(var i=0;i<items.length;i++)

    {

    if(items[i].innerHTML.indexOf('Resolve Call') > -1)

      {   // Resolve Call is the name of the UI action(not element)

    items[i].style.backgroundColor = "#74DF00";

    items[i].style.color = "#FFFFFF";

    // }

  }

}

gsftSubmit(null, g_form.getFormElement(), 'ResolveCall');

[Siddartha Gudim]

Hi Anusha,

How to change the button color of a scoped app form in ui16

Please follow link above it has more information about the DOM.

Please like, mark Helpful/Correct based on the impact of the response.

[Gaurav Bajaj]

Hi Anshul,

Please add below property in your scoped application.

glide.script.block.client.globals and set its value to false.

This will allow the global script object to run in the scoped app.

Thanks

Gaurav

[CJB]

This was the key to resolving my issue. Thank you.

[Chuck Tomasi]

I am putting this note only to state that the above solution requires customization (scripting). This is a classic case of communicating to those making such requirements the following facts BEFORE implementing them:

• This feature is NOT provided out of the box
• There is currently no known configuration to make the system behave this way
• It requires custom code - meaning it is something someone needs to build, document, test, and maintain
• Important: This customization violates best practices and puts you at risk for future upgrades (meaning it can, and likely will break in future releases of ServiceNow.)

If they accept these risks and costs, then you have the option of implementing it - and be sure to document it - very well so someone coming along in 2 years knows what it is, how it was built, what it is supposed to, and how to maintain it.