When rule using Future test fails when invalid date
All, I have a When rule executing a test of a date field for a null condition and whether the date entered is a future date using the "Date is in the future" condition. If an invalid date (like a String) is passed into the When rule the function fails rather non-elegantly. Should there be an enhancement to the function used in the "Date is in the future" condition (I believe it uses CompareDates under the covers) to test for an invalid date? Would this be considered a product defect and should I be raising an SR to address? Is this function working as designed and this is not an oversight but rather a design case with reusability in mind? Is the best practice to test first for the condition using IsValidDate first? What are some best practice patterns around this date evaluation and where else in the OOTB solution have you used them?
***Edited by Moderator Marissa to update categories***
Accepted Solution
Pegasystems Inc.
US
When you say this fails non-elegantly, can you describe the behavior?
And regarding using IsValidDate first, the software engineer inside of me would approve of this approach/local change. This is really similar to your null check. Ensuring valid parameters are being passed to your function before trying to process them safeguards you in case the developer of said function does not error handle for it.
But yes, ideally, error handling should be baked in where ever possible.
Wells Fargo N.A.
US
See attached screen print. I set the property to "wordsNotDates" and ran the When rule as originally setup in the previous screen print ... without the IsValid check in Step 1. It gives me a big red x kind of failure. To be fair, I'm only asking if this should be additional logic added to the OOTB function; baked in as you say. I think it's perfectly rational to expect a developer to test conditions beforehand.
NBFC
CA
What is the type of the property you defined to validate ? Is it Text or Date ?
Wells Fargo N.A.
US
it is a DateTime. The UI currently has no edit-input rule to clean it up though, I noted when I looked at the Section rule.
Wells Fargo N.A.
US
I've marked this as answered based on the feedback from Rett at GCS. I don't know that it was an answer, per se, but he certainly seems to think this warrants consideration and refactoring to make it a more complete error handling function.