The CreatorCon Call for Content is officially open! Get started here.

Read-only fields by UI Policy or Client script become editable after UI Action runs - why?

scottatah
Giga Expert

Hi Everyone,

 

I'm in the process of testing things for our upgrade to Eureka and I've discovered an bug in presumably our customization (exists in our current production instance (calgary) as well).   On our Change form, we've got a "Tested by" field.   We've made it read-only and added ref_contributions=add_me so that a user can only input their own name for sign off. It does it's job correctly until you click the "Request Approval" UI Action.   The Request Approval validates that all required fields are filled in and then requests the approval.   If not all fields are filled in, you're propted and required to complete all fields before moving forward.   As part of that the "tested by" field becomes editable allowing you to put in any user you want.


For whatever reason, the read-only portion was implemented with a simple onload client script, so I tried doing it as a UI policy, but there was no difference.   I'm assuming the issue is then in my UI action, but I'm not sure.  


Thoughts?

 

UI Action:

Condition: current.approval=='not requested' && gs.hasRole("itil")

Script:

function requestApproval(){

     

      g_form.setValue('approval', 'requested');

      g_form.setMandatory('assigned_to', true);

  g_form.setMandatory('assignment_group', true);

      g_form.setMandatory('start_date', true);

      g_form.setMandatory('end_date', true);

      g_form.setMandatory('u_after_hours', true);

      g_form.setMandatory('description', true);

      g_form.setMandatory('u_risk_analysis', true);

      g_form.setMandatory('u_communication_plan', true);

      g_form.setMandatory('change_plan', true);

      g_form.setMandatory('backout_plan', true);

      g_form.setMandatory('test_plan', true);

      g_form.setMandatory('u_tested_by', true);

      g_form.setMandatory('u_test_completion_date', true);

     

      //Call the UI Action and skip the 'onclick' function

      gsftSubmit(null, g_form.getFormElement(), 'request.approval');

}

 

 

// Code that runs without 'onclick'

// Ensure call to server-side function with no browser errors

if(typeof window == 'undefined'){

      serverApproval();

}

 

 

function serverApproval(){

      // Set the state to Undergoing Approval and the Approval field to requested, save the update and reload

      // the form, which starts the emergency workflow.

      action.setRedirectURL(current);

      current.approval='requested';

      current.update();

}

1 ACCEPTED SOLUTION

In the end, I added a reference qualifier of Sys id is javascript:gs.getUserID() to the field in question.



If they get the magnifying glass after the request approval fails, it limits their choice to only themselves and solves the root of my issue.


View solution in original post

9 REPLIES 9

I did try turning on debugger.   I'm a little new to using it, but I tried watching that field and it didn't provide any useful information (I don't believe)


field watcher.jpg



Looked through the javascript log of the debugger and while most of that doesn't make a ton of sense.   The only thing that happens after clicking the UI Action is below and I'm not totally sure what that means.


13:49:40 (589)change_request.dodirty form focus








Geoff, thanks for joining the discussion.   Please forgive me I'm an amateur when it comes to scripting, but I've tried commenting lines 17-21 and 22-39 out in my UI action with no change to the outcome.


ui action.jpg






Brute force method: Comment out all the functional lines. If it then behaves correctly, start un-commenting out the lines until it breaks. Then you'll know. If it still doesn't behave correctly, then it's not this script at all.


Masha
Kilo Guru

Looks like a perfect candidate for: Field Watcher - ServiceNow Wiki         Maybe you can see from there what changes your field.



My '2 cents': if "Tested By" is a custom field on Change Request only and should not be editable by the end user, why not make it "Read Only" through it's dictionary or an ACL? If it is not native to Change Request, why not create a Dictionary Override and make it Read Only?


mark_oldroyd
Tera Contributor

Hi Scott,


Did you ever get this sorted ?



If not one problem you might have is that if a field is set to Mandatory it cannot be Read-Only.


So once the script runs the Mandatory flag is overriding the Read-Only one.


In the end, I added a reference qualifier of Sys id is javascript:gs.getUserID() to the field in question.



If they get the magnifying glass after the request approval fails, it limits their choice to only themselves and solves the root of my issue.