So, I had an email from a guy called Maxim Semyonov, asking about getting an UpdateTask activity to, well, update a task, and did I have an example? Well, I did, although it didn’t really seem to help him very much – of course, there were problems between versions of SharePoint, installing InfoPath forms is always a giggle, and so on – but he did track down the issue, and it is an interesting ‘gotcha’.
What he was doing way using the same SPWorkflowTaskProperties for the OnTaskUpdated.AfterProperties, and the UpdateTask.Taskproperties. This seems natural enough – he wanted all the updated task data (in AfterProperties) in the task properties, so why not use the same object for them both?
Naturally, this doesn’t work
. The result was that the task didn’t update, and he was getting the error “Task update was not accepted“. Why, I don’t know – what Maxim was doing seems perfectly reasonable. Instead what you’ve got to do is write code to copy across all the properties you want. Crazy.
To be sure (i.e. to confirm what he told me) I was going to create a test workflow as he’d described – but I’d a vague feeling that I’d seen this before – and looking though my notes (yes, I keep notes. Rough ones. With doodles) I find that yes, this was the first thing I discovered when trying to use the UpdateTask activity. I’d just forgotten (and probably hoped it was a Beta thing). I wonder how many other folks have been caught out by the same problem?
It also explains why I wasn’t doing things in the way Maxim was describing – ‘cos it did seem reasonable, and a good way to reduce the number of SPWorkflowTaskProperties objects in your workflow…
(Note to self – remember this, and tell others)
Thanks in Advance
-Manoj Iyer
Globaltech India.
manoj@thegt.com