Skip to main content

Hi,


I have a workflow, which contains several activities. For each activities a webform is used for data input by the users.


In case the user doesn't complete the form and exits by closing the browser, I want to release the task.


To do this, I put an hidden asp:button on the page, which I trigger with Javascript on the "window.onbeforeunload" event :



    window.onbeforeunload = function() {


        document.getElementById("<%=Close_btn.ClientID %>").click();


    };


The code behind the button is quite simple :



cnx.OpenWorklistItem(SN).Release()


Where "cnx" is my connection to the K2 server and "SN" is the serial number of the task.


It seems to work well, except for the activities assigned to sharepoint groups.


For these activities, the "Release" instruction does not throw any exception, nor does it actually release the task.


Being kind of a newbie to K2 development, I'm perplex to say the least.


Is this some kind of bug of K2 with activities assigned directly to SharePoint Groups (without using K2 Roles) ?


Or do I miss something ?


I saw a "OpenSharedWorklistItem" on the "Connection" object, but I don't think this is what I'm looking for.


 


Thanks in advance for your time.


Nicolas

Thats an interesting situation, for the times when it does not work the only difference between the activities is the destination user?  There is no difference between the destination rules or plan type?

Try taking the code out of the testing.  Does the same problem occur if the same user manually tries to Release the task using his K2 Worklist?


Similarily does the problem occur if a Workflow Administrator releases a SharePoint group user task.


Not a solution but hopefully it'll narrow the issue.


 

This is not so much a bug as a known limitation. You cannot use the Management Worklist/API to release open worklist items assigned to groups. This is because it affects slot calculations. To release a worklist item assigned to a group, you must impersonate the user who has it open, and do the release from there.


HTH


Gail

Hi,


Thanks a lot for the quick answers !



Thats an interesting situation, for the times when it does not work the only difference between the activities is the destination user?  There is no difference between the destination rules or plan type?




The workflow is very simple in its design. Only one slot per activity, no destination rules that I know of.


 



Try taking the code out of the testing.  Does the same problem occur if the same user manually tries to Release the task using his K2 Worklist?


Similarily does the problem occur if a Workflow Administrator releases a SharePoint group user task.


Not a solution but hopefully it'll narrow the issue.



When the user tries to release de task from his worklist, it works. From the K2 workspace, it works too.


When I look at the connected user (the one linked to the open "connection" object), I see the user who has opened the task. But the release instruction doesn't work.


 



This is not so much a bug as a known limitation. You cannot use the Management Worklist/API to release open worklist items assigned to groups. This is because it affects slot calculations. To release a worklist item assigned to a group, you must impersonate the user who has it open, and do the release from there.



So I just can't do this by code ? If that's true, would it be easier if my group was a K2 role instead ?


The impersonation thing is valid in a code situation or does it just mean "login as the user, and release the task from the graphical worklist" ?


 


Thanks again,


Nicolas


 

You can do this by code. You must use the Impersonate method, to do the release as the end user.


You can release the worklist item by using ImpersonateUser() in SourceCode.Workflow.Client, if you know which user has the item open. Impersonate that user in code and then release the item as that user.

HTH
Gail

Ok I will try forcing the impersonation.


I thought there was no need to do this, bescause the connection is open with the right user by default (checked the cnx.User property).


I'll give it a try as soon as I have access to my client's environment :)


 


Nicolas

Great, let us know how it goes!

Hi again,


It seems to have worked.


I don't understand why as the user connected to the K2 server hasn't changed with the call to ImpersonateUser, but whatever... :p


I'll do some more tests to be sure.


Thanks for the help

Hi,


The problem's back. It seems the solution provided works only in the debug mode of visual studio.


My development machine different from my K2 / SharePoint server for the development environnement.


My forms are developped as an ASP.Net web application. Once published, the forms are in a virtual subdirectory of my sharepoint site (from an IIS point of view), same as the _layouts or _controltemplates folders.


 


So, when I test my page in visual studio (right click > view in browser) it works well, and my task is released as expected.


But, when I deploy the web app, the task is not released anymore.


 


So I do an impersonation at SharePoint's level (SPSecurity.RunwithElevatedPrivileges), and then open a new connection to the K2 server with the pool Identity (who has all permissions granted on the process) and release the task, but the task remains "Open".

We're starting to dig past my comfort level here, but...


SharePoint impersonation is not the same thing as K2 impersonation. Here's what I would check for:


In the K2 Host Server log, look to see which user actually connects to K2 from SharePoint. If it is the application pool identity, you need to make sure the application pool identity has "Impersonate" rights in K2. If it is the end user's identity, it SHOULD be working. If it's "NT AUTHORITYANONYMOUS LOGON", then the user context isn't coming across from SharePoint, so K2 may not know who/how to impersonate. If it is coming across as anonymous, try enabling Pass-Through Authentication in K2.

I'm curious if the correct user is being determined in Sharepoint when the page is open.  Maybe you've already tested this but if not as a quick test add a textbox to the page that shows the user name when the form is opened.  Hopefully this can help narrow your troubleshooting.


I have seen it where the web.config impersonate settings haven't transferred when I've deployed a web project.

During my tests I could see that :


- Identity in SharePoint is the correct user (the end user to which the task is assigned)


- Identity in K2 is also correct (same user)


To be sure, I impersonated to the pool user, who also as administrative rights (including "Impersonate") in K2. This user opens a new connection to K2, then impersonate as the end user and release the task.


It seems to work as well as the other method.


I now think the problem is about communication between IE (click on the close icon) and javascript (activation of the button and call to the release method). When I display the button on the form and click on it, the release is done correctly. It's only when the button is activated by javascript that it  doesn't work on the task assigned to SharePoint groups. On the tasks assigned to a single user, it works everytime O_o.


Thanks for your help !

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings