CSWeb failure with RFC3339 and CSPro is thinking that all is ok
Posted: September 8th, 2020, 2:35 pm
We are using CSPro/CSWeb 7.4 but CSWeb have a problem to check the schema format of the json that CSPro is sending to the server. Exactly the problem occurs checking the date-time format Rfc3339 of the interview notes.
We temporary fixed the problem commenting the related code in CSWeb:
But when the problem occurs in CSWeb, an Exception is throw and all cases after the offending case was not process in the server. This can be understand, but the problem, is that CSPro now is thinking that CSWeb have that cases when really he don' t have them.
To be worse to us, like we not let to modify a case when is finished, the interviewer can not touch this cases now and them they can not be marked as modified to be sended again.
Question: How we can resolve that situation that we have?
A CSPro bug that we think need a fix:
CSPro need to be improved to the point it detect the problem in CSWeb and avoid to mark the cases as send when they was not really save in CSWeb.
We temporary fixed the problem commenting the related code in CSWeb:
Code: Select all
case 'date-time':
//if (null === Rfc3339::createFromString($element)) {
// $this->addError($path, sprintf('Invalid date-time %s, expected format YYYY-MM-DDThh:mm:ssZ or YYYY-MM-DDThh:mm:ss+hh:mm', json_encode($element)), 'format', array('format' => $schema->format));
//}
break;
To be worse to us, like we not let to modify a case when is finished, the interviewer can not touch this cases now and them they can not be marked as modified to be sended again.
Question: How we can resolve that situation that we have?
A CSPro bug that we think need a fix:
CSPro need to be improved to the point it detect the problem in CSWeb and avoid to mark the cases as send when they was not really save in CSWeb.