Prevent Submission of Catalog Item With a Date in the Past

jmiskey
Kilo Sage

We have many Catalog Items that have a date field like "Effective Date", where the date entered cannot be in the past.  We have always handled it with a On Change Catalog Client Script, right on that date Variable, to do a GlideAjax call to a bunch of date functions to check/verify the date is not in the past, and this has always worked well.

 

However, with the most recent versions of ServiceNow, it now has/allows a "Save as Draft" option for Catalog Items.  So now people could enter an Effective Date of today, and then save the Catalog Item as a draft.  They could then re-open that draft tomorrow and submit it.  We do not want to allow that to happen, as tomorrow, the date they entered in the Effective Date field will be in the past, and therefore should not be allowed.  So I think we need to add similar logic that we have in the On Change Catalog Client Script to an On Submit Catalog Client Script.

 

When I tried doing that, it did not work.  It ran, but did not prevent the record from being submitted like it should.  From research, it appears that you cannot use GlideAjax calls in On Submit Catalog Client Scripts.  So what is the best way of handling this?

 

Here is the I attempted, which uses the same logic/GlideAjax call as my On Change Script:

function onSubmit() {
   //Needed due to the ability to "Save as Draft"

	var dndt = g_form.getValue('effective_date'); //First Date/Time field  
    var dttype = 'day'; //this can be day, hour, minute, second. By default it will return seconds.  

    var ajax = new GlideAjax('global.ClientDateTimeUtils');  
    ajax.addParam('sysparm_name','getNowDateTimeDiff');  
    ajax.addParam('sysparm_fdt', dndt);  
    ajax.addParam('sysparm_difftype', dttype);  
    ajax.getXML(doSomething);  

    function doSomething(response){  
        var answer = response.responseXML.documentElement.getAttribute("answer");  
        //check to see if request for old date (by seeing if difference between now and request date < -1)  
        alert(answer);
        if (answer<=-1) {
            alert("Effective Date cannot be a date in the past!");
            g_form.setValue('effective_date','');
			return false;  //disable submission
        }else{
			return true;
		}
    }  
   
}

Thanks

1 ACCEPTED SOLUTION

Zach Koch
Giga Sage
Giga Sage

Unless you need more data from the server, you can actually just prevent past dates through UI policy where it will clear out the value if it is in the past, which will prevent people from being able to save a draft like you mentioned, with the date in the past. Take a look at this post.

No Code date validations through (Catalog) UI Policies 

If this information helped resolve your issue, please remember to mark response correct and thumbs up to help future community members on this information, thanks!

View solution in original post

18 REPLIES 18

Zach Koch
Giga Sage
Giga Sage

Unless you need more data from the server, you can actually just prevent past dates through UI policy where it will clear out the value if it is in the past, which will prevent people from being able to save a draft like you mentioned, with the date in the past. Take a look at this post.

No Code date validations through (Catalog) UI Policies 

If this information helped resolve your issue, please remember to mark response correct and thumbs up to help future community members on this information, thanks!

I think you misunderstood my issue.  The date isn't in the past when they enter the data into the field, it is when they submit with form (which now can be different dates, due to the new "Save as Draft" option.

 

For example, they enter today's date in the Effective Date field (10/9/2024).  That is not in the past, so it is a valid entry.  However, after completing all the fields, they elect to "Save as Draft" instead of submitting the form.  Now let's say that tomorrow they re-open that draft, don't change any fields, and click Submit.  The Date field isn't being touched/changed, so no On Change Catalog Client Scripts would run.  And I don't know that any UI Policies would fire.  But the request should not be able to be submitted, because now that they waited a day, that Effective Date field value they entered yesterday is now in the past.

 

Does that make sense?

Actually, it took me a while to understand how I might use this, but I think this may work, if "On Load" causes it to run when they re-open it from Draft.  I set up a test, where I entered today's date and saved as draft, and will open it tomorrow and see if it works.

 

I will post back my results tomorrow.  I am cautiously optimistic!

This way worked beautifully, and is so much simpler than using GlideAjax.

 

Here is what the two key screen of my Catalog UI Policy ended up looking like:

jmiskey_0-1728643943682.png

jmiskey_1-1728643973412.png

 

So simple and effective!

Thank you very much!