Date variables on RITM have corrupted value

chrisperry · ‎06-29-2017

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

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry

chrisperry · ‎08-30-2017

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.');

                   }


         }

}

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry

View solution in original post

Harshit · ‎06-29-2017

Hi Chris,

Where are you mapping the Start date on the catalog with the Start date on the RITM??

Also are both the field types same - Date or Date/Time ?

Thanks,

Harshit

chrisperry · ‎06-29-2017

Hi Harshit,

Thanks for your response.

The Start Date variable is the same variable in the catalog as it is on the RITM - it is not mapped to an actual field on sc_req_item, it is just a variable from the catalog item. What I have shown in that report is the actual variable:

The variable type is Date.

Thanks,

Chris

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry

Harshit · ‎06-29-2017

Hi Chris,

Can you please check what the value shows up when you report on "Variable Ownership" (sc_vat_item_option_mtom) table.

Parent item (RITMxxx)

Parent item.Item (Catalog item)

Dependent item.Question (Start date)

Dependent item.value --> stored value of start date

Thanks,

Harshit

chrisperry · ‎06-29-2017

Hey Harshit,

Here is what I see when I pull the report you recommended:

Thanks,

Chris

If this answer is helpful please mark correct and helpful!

Regards,
Chris Perry