GlideModalForm: has anyone used addParm or setPreference?

tahnalos
Kilo Sage

One of my ongoing tasks is to find a way to create dialogs to pop up to prompt users to enter additional information before they can access a ticket.   Someone recently pointed me to GlideModalForm, which has a lot of prebundled options on how you want the dialog to work.   Seems to be working fine except I'm missing a critical piece of information:

I need to pass additional information to the dialog itself opened in GlideModalForm, and the documentation suggests to use either addParm and setPreference.   The only issue is that the documentation is very vague on how to use this (which is why I loved the wiki so much more), and that examples provided by others seem to suggest that addParm and setPreference only allows for certain arguments on how the window is to look, and not whether to pass information from one form to another (these examples use sysparm_* variables so I don't think that is correct).   Can anyone shed some light to me for this?

Thanks

1 ACCEPTED SOLUTION

adam_faulkinber
Kilo Expert


var d = new GlideModalForm('Create New incident', 'incident');


d.setOnloadCallback(populateModal);


d.render();



function populateModal(){


        //Access GlideModal g_form


        var d_form = window.frames["dialog_frame"].g_form;


        d_form.setValue('caller_id', g_user.userID);


       


        //Access GlideModal Scratchpad


        var d_scratchpad = window.frames["dialog_frame"].g_scratchpad;


        d_scratchpad.myVar = 'Scratchpad Value';


}





You have to access the Modal using window.frames["dialog_frame"].


View solution in original post

13 REPLIES 13

Goran WitchDoc
ServiceNow Employee
ServiceNow Employee

Hi,



Can you be a bit more specific what the requirements are here.


Is it through the normal UI or Portal?



You write "access a ticket". Is this something that should popup before the create a ticket or always when they try to click on an existing ticket?


Is it before the user actually see the ticket or is it for example on submit?


This is through normal UI.   This is something that should pop up before they click on an existing ticket as additional information may be required before access to the ticket itself is given.   Ideally, this should run onLoad, so to handle the following situations:


1) If this is the user's first time accessing the ticket and they have not provided additional info, it will prompt them to do so via the GlideModalForm dialog.


2) If this is NOT the user's first time accessing the ticket and they have provided some info, the dialog will pop up again until all pertinent info is provided.


2) If they have already provided additional info, and the info has NOT been confirmed by an additional party, they can access the ticket but it will be locked down.


3) If they have already provided additional info, and the info has been confirmed by an additional party, they can access the ticket and will be editable.



Hope this helps.


Bump.


When you talking about user. You are talking about the end user or the assignee?



1 & 2 Seems pretty much the same behavior. it doesn't matter if it's the first or not, if the additional info isn't filled in, the window should popup


3 & 4 I'm guessing you will need to solve with UI policies. Preferable ACLs, but those are loaded when the record is loaded, so if it's missing data then, it locks the record from edit, and don't care if the user fills in the add. info.



Problems: this add. info, is that data that should go into fields within the form it self? If it is, might be hard since they field is then locked from edited since they haven't filled in the info...



IF the fields are on the record, how about this:


Make ACLs so that only the fields which requires the add. information is open for edit. And when all those fields are filled in and saved, the rest will be editable as well. Then you can have a onLoad client script throwing up a message about filling in those fields first before being able to do anything else. Easier way would be using UI Policies, but that isn't really security and can easily be sidestepped by anyone know a tiny bit if html and use of web tools in the browser.