Date variables on RITM have corrupted value

[chrisperry]

Hi,

I am having a very difficult time with figuring out what is causing a date variable to sometimes have a corrupted value (in this screenshot, 'Start Date' is a date variable on the catalog item: CMG Provisioning):

I opened a ticket with HI support on this issue, and they responded that they believed the value might be getting corrupted due to PRB759180 - which essentially documents the lack of OOB functionality within service portal to validate the format of the date variable selection.

To resolve that issue, I wrote a bunch of onChange catalog client scripts for date variables that are present on our service portal which validate the date format via regex - and if the user types in an invalid format, their input will be cleared out and they will see an error message to use the calendar icon instead:

As such, I have concluded that PRB759180 is not the culprit here.   We do not have any business rules or workflow configuration which touch that Start Date variable either, and I basically cannot figure out what is causing this issue to continue to occur.   I implemented those regex date validation client scripts back on 05/25/17, and as is shown in the screenshot from the report above, there are still RITMs coming in with corrupted date values as recent as 06/29/17.

Does anyone have any ideas on what might be causing this issue, or any ideas on how to further troubleshoot?  

Part of what makes this issue so hard to figure out is that I haven't been able to lock down the steps that users are taking to reproduce this issue... Any feedback would be greatly appreciated!

Thanks,

Chris

[SusanWinKY]

Hi Christopher,

Did you solve this?   We're seeing the same thing.   Any request submitted via the Service Portal has this corrupted date format, while requests submitted via Service Catalog are fine.

[chrisperry · Accepted solution]

Hi Susan,

I did solve this - I am guessing you are on a Helsinki version earlier than Patch 8, which means you are encountering this problem: KB0610289 (date format not honored in Service Catalog area of Service Portal).

So whenever you select a date from the calendar in Service portal, the text input is in yyyy-MM-dd format, which I am also guessing is different from your instance's system default (glide.sys.date_format property).   That is where the issue occurs, because the Service Portal default format is different from your overall system's default format - there seems to be some kind of corruption on that value when the transaction occurs and the database is trying to record that date value.

So, the solution I figured out was to write an onChange catalog client script for the date variable which uses regex to check if the format is in yyyy-MM-dd (such is the case if user picks date from calendar picker), and then to parse that value and rearrange it into my system's default format (MM-dd-yyyy).   Then the script runs a final check to ensure that the input is in MM-dd-yyyy format, because users don't necessarily always use the calendar picker and could type in a bogus date format instead.   By validating that the date input's format on Service Portal is the same as your system's default date format, the date corruption will no longer occur.

Here's the script that I used for onChange of a 'start_date' variable:

function onChange(control, oldValue, newValue, isLoading) {
     if (isLoading || newValue == '') {
           return;
     }
         g_form.hideFieldMsg('start_date');
         var isPortal = window === null;
         if(isPortal){
                   var dateVal = newValue;
                   //regex for yyyy-MM-dd date format, format user gets if they select date w/ calendar picker
                   var regPatternCal = /^(19|20)\d\d(-)(0[1-9]|1[012])(-)(0[1-9]|[12][0-9]|3[01])$/;
                   //regex for MM-dd-yyyy, format we want the date selection to end up in
                   var regPatternEnd = /^(0[1-9]|1[012])(-)(0[1-9]|[12][0-9]|3[01])(-)(19|20)\d\d$/;

                   //check if date selection in yyyy-MM-dd format
                   var checkArray = dateVal.match(regPatternCal);
                   if(checkArray != null) {
                             var dateString = dateVal.toString();
                             var year = dateString.substring(0,4);
                             var month = dateString.substring(5,7);
                             var day = dateString.substring(8);
                             //g_form.addInfoMessage(month + '-' + day + '-' + year);
                             g_form.setValue('start_date',month + '-' + day + '-' + year);
                             return;
                   }

                   var checkArray1 = dateVal.match(regPatternEnd);
                   if(checkArray1 == null) {
                             g_form.setValue('start_date','');
                             g_form.showErrorBox('start_date','Invalid Start Date. Please select using the calendar icon.');
                   }

         }
}

[SusanWinKY]

Christopher, thanks so much!   We'll take a look at this and see if it will work.   We're on Jakarta (first release).   🙂

[robertlankford]

This is good stuff.   I just tried it myself in our Service Portal instance.   I created a catalog script against a variable set containing a date field.  

But, the behavior isn't as I would expect.   There are two issues.   First, we seem to always have an error message displayed on screen after the date gets corrected:

I am assuming that line 5 in the script above invoking hideFieldMsg is supposed to be clearing this out.   But it doesn't seem to be working for us.

The second issue happens when we pick a date with a day less than 12.   The wrong year gets displayed.   For instance, I'm going to select September 1, 2017.   I see this as a result:

And then the calendar gets shifted to 2009 too.   That's a weird side-effect.   Is anyone else seeing this?   Any ideas?

Jakarta - Patch 0

[chrisperry]

Hi Robert,

Could you please post the script you are using?   You are correct for the error message that line 5 should be clearing out the field message, but I am guessing the 'addErrorMessage' method is getting called again later when you don't want it to be.

As far as the day less than 12, that is definitely a strange one - I have not seen that before.   That said, I see that you are trying to end up with a format of YYYY-MM-DD - so your regex will be different than mine, and there may be an issue with the regex you are using.   Thinking about that a little bit more, it actually makes sense that the error message is still being displayed because you are asking for YYYY-MM-DD and the values in your screenshots are in MM-DD-YYYY format.

Thanks,

Chris