If you are getting validation errors on the Service Catalog variables, specifically for the type "date" or "date/time" variables or your users are complaining about not being able to submit requests due to invalid text errors; then you are in the right place! If you are getting a "The following fields contain invalid text: Enter Date" message, I have some details for you.
NOTE: Post Helsinki, if upgrading to Istanbul and up, validation scripts are available and should resolve manual troubleshooting of validation errors on catalog date/time.
This issue is more common in the instances which recently upgraded to Helsinki. We enforced validation scripts on Service Catalog variables starting in the Helsinki release. Before Helsinki, the validation worked only on form fields but not on catalog variables. No validation on variables caused its own data corruption issues and a lot of us had to either run data cleansing of some form or wasted time in going back and forth with the requester; thereby increasing the resolution/procurement times and negatively impacting the user experience. This tends to happen in global deployments.
The "date/date-time" variable displays a date picker or calendar to enter date in the correct format; however, if the users wanted to add text or numbers instead, they could do that.
Example of a user with a system date format error
Once you upgrade to Helsinki, the date validation script compares the input date format with the date format setting in the user record. For example, the user below is set as system date format and tries to enter the date as MM-DD-YYYY.
The default system date format is yyyy-mm-dd
Now in a date variable, if he/she tries to enter the date in dd-mm-yyyy format, will get an error saying "The following fields contain invalid text: Enter Date."
Or if he/she tries to anything other than the date/time, will get an error:
However, an empty date is still a valid entry unless you make the variable mandatory. So if you submit the order without anything in the date variable, it will get submitted and generate a RITM:
Now if you are unhappy with this or need to change something in how the validation works. Then all the validation scripts can be found under System Definition > Validation Scripts.
The specific, Date/Time validation function is here:
Modifying the Date/Time validation function
If you decide to make modifications to it, we recommend making a copy and make changes to it. You will need to also deactivate the original one. The default function first checks if there is a value in the variable or not. As I said before, we consider no value (!value) as a valid date:
If there is a value in the date variable, it is compared with the user date time format defined in user record (g_user_date_time_format) using "isDate" method.
The same validation script applies to "Date" type variables as well.
In case you have created a custom validation script for "Date" type variable, then the "Date/Time" validation script will take precedence.
Please feel free to modify the base system validation script to meet your needs, just remember to make a copy of it and then keep only the desired script active. You can also choose to deactivate the script completely if you do not want any validation be done. Likewise, you can review or modify other validation scripts for variables like Email, URL etc.
If you make any change to the validation scripts here, they will affect both the catalog variables and the Form fields.
In case you decide to either completely write a new client script or make customizations, I would suggest the best practice to use only supported client script APIs so that it also work on Service Portal. You may also be interested in reviewing this Knowledge article that talks about a less common issue related to date/time variable which was fixed in Helsinki Patch 6.
2 Comments
