When logged in to server as different user than the Administrator and running the Workspace (run as) as the Administrator, when you open the web integrated InfoPath form the new IE window authenticates with the user logged in to the server which is not the Administrator and, which is not a destination user and therefor cant action the item. To fix this we suggested changing the InfoPath Client to allow all users to complete the item. I think there are known issues with this method. 

The other option is to go to WorkSpace > Management Console > WorkFlow Server > Processes > Open the process and then add the users that are used to log in to the server under EACH of the actions with Allow rights. A better alternative will be to create an AD Group, adding the users that need the Allow rights to the Group and adding the Group to each of the actions with allow rights.

As far as the escalation / Expired goes, you can refer to the following link http://www.k2underground.com/blogs/fromthebench/archive/2008/04/04/how-to-add-code-in-a-default-escalation.aspx

vernon

Hi Vernon,

Thanks very much for getting back to me.

I am not sure if I made myself clear here - it is not the admin getting the "No actions available for this task" that is the problem , it is the person whom the task is assigned to.

So basically, the task is assigned to user "bob", but when "bob" opens clicks the task to open the infopath form, there are no actions available for him to complete the task

Note that "bob" has been able to complete tasks in the past - it is only this process that has encountered the problem.

Did you put the correct link in above - it links through to a blog entry on how to add code in a default escalation - I can't see how this can help me? Maybe I am missing something here?

Thanks again for your assistance - please let me know if I need to further clarify anything.

Hey there,

I've had a similar problem. This occurred after I made a bunch of changes to the workflow. In the end I just went back into InfoPath Client Events >Configure Actions. Then I deleted the existing actions and made them from scratch. After that it worked again and this was true for all stages of the workflow which had the same error.

Hope that helps =)

sphynx

Hi sphynx, thanks very much for getting back to me.

This sounds like a similar problem - I did make some changes to the process which were recently deployed to production, however the 2 process instances in particular which have been reported to me are both instances that were started on the previous version of the process - as far as I understand, any processes already running when a new version of the process is deployed should continue to run on the version of the process on which they were initiated?

If this is the case, it doesn't seem likely that re-configuring the actions would have any affect on previous versions??

Please let me know if you have found otherwise?
Were you getting this problem on instances that were started on the original version of the process, or only on instances started with the updated version of the process?

Thanks again for taking the time to help with this - I really appreciate it!!

Hmm, that sounds really strange, I wouldn't have expected it to stop working for existing instances. Still, I'm assuming that the problem only arose after the changes were made to your workflow? That was the case in my situation though I didn't have any older instances to check whether the situation is the same as yours.

Basically, I haven't had experience in your exact issue as far as I can tell but I must say that I still strongly recommend giving the fix I mentioned in the last post a try.

I hope that helps.

Best of luck!

sphynx

I realize this is a really old thread, but I just had an issue where I was bit by a bug.. Our K2 database got corrupted. We opened a ticket to get the fix, which was a SQL script that re-populated the table that held which processes were deployed. However, we then had to re-deploy every process. So we had running instances on the old version and they could not be actioned. Initially, they would see the option to complete the task, but submitting the InfoPath form did not actually do anything. The task remained in the user's worklist.

So... There is a utility out there in the Market called  "Process Instance Version Migration Utility". Unfortunately, in it's current published state, it won't work for 4.6.7.  I had to get into the source and make changes for the database queries to the proper table names. If you're interested, track me down. I'm not a good developer, so I don't want to publish my changes for fear that they're not fully baked. I can eat my own pain, but would hate to inflict pain on someone else if I've coded a mistake.