Inside our document model, we are having a validation rule for a DateTime field, whose condition is described below:
Now > [fieldDateTime] //fieldDateTime is not in the past
Our business case is that when the fieldDateTime is expired, there is a triggered job to change the value of the Status field of the document. However, at this point, because the fieldDateTime is already expired, which conflicts with the validation rule above, we cannot modify the status of the document (get an error that indicates the fieldDateTime is not in the past). Is there a way to bypass validation rules in this case or any alternative ideas?
Hi @hieu-far-field,
It seems that you have a field on the document model for the status. Could you reference both fieldDateTime and fieldStatus in the validation? For example, fieldStatus is an Enumeration with two values, “firstValue” and “secondValue”:
Now > [fieldDateTime] And [fieldStatus] == "firstValue"
This error condition would fire if fieldDateTime was in the past but fieldStatus had not been updated to “secondValue” by triggered job.
Hi @malcolm-silver-ice,
Thanks a lot for your reply. We implemented that approach and it worked as expected. However, from the technical point of view, we do not want to have a strict constraint between fieldDateTime and fieldStatus since in the future, there might be some more statuses and it could be complicated to adapt.
You could consider keeping the status field outside of that document.
I think that is a better approach since the status is rather meta data than actual document content.
If you want to keep using the document modelling capabilities, you can wrap the actual document with a “DocumentWithStatus” type of document by including the actual document into the one that only adds a status field on top.
This include could be configured to exclude the validation rules. Then you can modify the composed document without issues. The actual document stays free of the status field.