error saving workItem. isValid returns true though

Question

We have found a case where workItem.isValid returns true, but calling workItem.save results in an exception ("Workitem 0 could not be saved - Application Error").

This is the problematic attribute we set:

workItem.getFields()
.getField("[id]")
.setValue(new Date(NumberUtils.toLong(dateValue, Long.MIN_VALUE)));

In some cases, dateValue was an empty string, which led to the date being set to Long.MIN_VALUE.

Now we understand (and have fixed) that an empty string does not result to that field being set.

However there seems to be a problem in handling this case in TEE correctly, as one would expect isValid to make the necessary checks so save would then work.

Answer 1

Unable to reproduce the case, i have done the following,

workItem.getFields()
.getField("[id]")
.setValue(new DateTime.MinValue));

workItem.IsValid();

returns true and saves the work item. 

Please share more details to reproduce the error.

Cheers, Tarun

---

Please remember to mark the replies as answers if they help.

Blog: http://geekswithblogs.net/TarunArora  Subscribe in a reader

Answer 2

Hi Tarun,

I just gave this a try, here is what I found:

A dateTime field (not required) is set to

workItem.getFields().getField(changedAttribute.getId()).setValue(new Date(Long.MIN_VALUE));

This consistently results in workItem.isValid to return true, but workitem.save to result in the following error:

TECoreException  (id=13783)	
	cause	SOAPFault  (id=13785)	
		actor	null	
		cause	null	
		code	QName  (id=13791)	
		detail	DeferredElementNSImpl  (id=13792)	
		detailMessage	"Error in the application. ---> Error in the application." (id=13788)	
		language	"en" (id=13793)	
		stackTrace	null	
		subCode	SOAPFaultSubCode  (id=13794)	
			subCode	QName  (id=13798)	
				localPart	"q0:Application" (id=13800)	
				namespaceURI	"" (id=190)	
				prefix	"" (id=190)	
	detailMessage	"Error in the application. ---> Error in the application." (id=13788)	
	stackTrace	null	

In you example, you did "new DateTime.MinValue" (which somehow I fail to see using the 10.1 TEE), which seems to work. But created a Date object with Long.MIN_VALUE doesn't seem to.

Now setting it to such a value is stupid, I understand, but nevertheless the TEE saying it's valid but failing on saving probably means there is some check missing.

 

Answer 3

Thank you Thomas.  I will enter a bug for this scenario.