I can't think of any way to do this out of the box, so you might be stuck writing a record to a table somewhere in your InfoPath form open rules that indicates who opened a task. Then, your process can get this information via smart object to get a list of users to notify.
Well that's unfortunately not good enough for two cases. If user clicks open task button but somehow he blocks the form being opening say close before it renders. The task will leave open and I won't be able to detect it. Second case if he releases the task from worklist I am stuck again since I won't be able to detect the closing. I think the information should be held somewhere but where ?
Try taking a look at the K2Server._WorklistSlot table. That contains all the tasks created and the status indicates whether or not the user has opened it. I'd like to think that there was a better way to get to this information, but I'm just not sure.
I think that status is slot status which can be Active, Empty, Expired ... It won't indicate the openness. I found a better solution. The openness is defined per worklist item. So on my server event I open a connection to Global Worklist do the filtering and get the Worklistitem ,there I can see the opener. A sample code for my case is as follows:
SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder connectionString = new SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder();
connectionString.Host = "localhost";
connectionString.Integrated = true;
connectionString.IsPrimaryLogin = true;
connectionString.Port = 5555;
WorkflowManagementServer ws = new WorkflowManagementServer();
using (ws.CreateConnection())
{
ws.Connection.Open(connectionString.ToString());
foreach (SourceCode.Workflow.Management.WorklistItem worklistItem in ws.GetWorklistItems(DateTime.MinValue,
DateTime.Now, "", "", "","Recipient Client Event",K2.ProcessInstance.Folio))
{
if (worklistItem.Status == SourceCode.Workflow.Management.WorklistItem.WorklistStatus.Open)
{
K2.ProcessInstance.DataFieldse"Recipient_Opener"].Value = worklistItem.Destination;
}
}
}
}
}
I think that status is slot status which can be Active, Empty, Expired ... It won't indicate the openness. I found a better solution. The openness is defined per worklist item. So on my server event I open a connection to Global Worklist do the filtering and get the Worklistitem ,there I can see the opener. A sample code for my case is as follows:
SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder connectionString = new SourceCode.Hosting.Client.BaseAPI.SCConnectionStringBuilder();
connectionString.Host = "localhost";
connectionString.Integrated = true;
connectionString.IsPrimaryLogin = true;
connectionString.Port = 5555;
WorkflowManagementServer ws = new WorkflowManagementServer();
using (ws.CreateConnection())
{
ws.Connection.Open(connectionString.ToString());
foreach (SourceCode.Workflow.Management.WorklistItem worklistItem in ws.GetWorklistItems(DateTime.MinValue,
DateTime.Now, "", "", "","Recipient Client Event",K2.ProcessInstance.Folio))
{
if (worklistItem.Status == SourceCode.Workflow.Management.WorklistItem.WorklistStatus.Open)
{
K2.ProcessInstance.DataFieldse"Recipient_Opener"].Value = worklistItem.Destination;
}
}
}
}
}
That is nice idea, but is it supported to call WorkflowManagementServer from a server event?
I am looking for a solution to the same problem and didn't find the answer till now.
regards.
hey, there is a method to get the worklist item by the procinstid, if you get the worklist item and it's status is opend or allocated, then you can find the allocatuser of the worklistitem, that's who open the worklistitem.
FYI:
WorklistCriteria wcInst = new WorklistCriteria();
wcInst.AddFilterField(WCLogical.And, WCField.WorklistItemOwner, "Me", WCCompare.Equal, WCWorklistItemOwner.Me);
wcInst.AddFilterField(WCLogical.Or, WCField.WorklistItemOwner, "Other", WCCompare.Equal, WCWorklistItemOwner.Other);
wcInst.AddFilterField(WCField.ProcessID, WCCompare.Equal, ProcessInstanceID);
conn.Connection.OpenWorklist(wcInst);
Derek,
you are referencing WCField.ProcessID which I believe is different from ProcInstID.
Are you sure this works?
The issue is not that I can't find the allocated user,
but the allocated user is always pointing to the group not to the user when I create one slot for the group instead of resolving the group to its users.
Regards.
