Good question!!!! Gonna be watching this post to see how/if its done!!! Some dates are transferred to other applications (e.g. Incident) and throw errors. There should be a way to validate some data!
Is it AIF or standard service request?
If it's standard service request the questions are built dynamically so you can't do those kind of things.
Thought so... but one can dream!! HA.
Same here. We just went live with SRM last week and have requests that are failing to fulfill because of the past date/time.
... I have an idea though I am going to try in a little while...
Adding some js codes directly in the SRS jar for the date types? Or at submit?
In 8.1 I wonder if you can test the date/time field compared to $DATE$ (or whatever the keyword is) (I don't think so though, if memory serves you can't use some field types in actions) in an action "answer question" and set the field to nothing.
If the date/time is required data then you wouldn't be able to submit the service request.
1 of 1 people found this helpful
I am talking this over with my coworker now. I had not seen this reply but I told him I bet Laurent Matheo knows how to "hack" the JS to compensate
I think what we are going to do is created a filter on SRD:MultipleQuestionResponse that will:
- look for the text "Requested Due Date%"
- if the answer is less than $SERVERTIMESTAMP$ +60*2 (give some time for fulfillment to kickoff)
- Add $SERVERTIMESTAMP$ +60*60*24 to add a day to the current time
We have advised our users that none of our current offerings have less than a day turn around so setting one day out will be fine. As long as we always use "Requested Due Date" in our SRD questions this rule will apply. If we ever want to ask something like "when did this issue start" for an Incident SRD the question text will be different and our filter will not fire.
Not ideal but it will get us by until the product can address this scenario.
Looks simple so better than my idea
Mine was a bit more complex eh eh
Create a hidden field question with a value (like "SERVREQUEST123").
In the .jar in the template html used (or any general file) put some js code that would check if there is a hidden field with this value.
So somekind of adding extrat logic for a specific service request, but well... Looks quite complicated and not easily maintenable.
I would really like some help on how you manage to do the date check on SRD for a specific question on a SRD before its submitted by the user. Can you provide a step by step guide on how you did this? and how you manage to populate a error?
Thanks in advance
Actually this was the subject of two breakouts, at Engage 2014 and WWRUG13.
I'm trying to see if they are ok for me to release the material, if so I'll release it, if not, I will have to do another example, and this might take time, sorry...
Did you ever come up with a response on the break out sessions?
I see this as a major limitation for the SRM module. The lack of the ability to validate fields in an industry standard way. We have run into multiple cases of this in implementing SRDs and has been frustrating to say the least that the product does not provide this ability. With the advances of client side validations and consuming external APIs, this would be a feature that is in high demand. I know for us, this is a deterrent from implementing any SRDs that need to validate data that is not sourced from within Remedy.
3 of 3 people found this helpful
Not sure if BMC have stopped the JS from running as yet though.