locked
Workflow task assigned to a SharePoint group gives error when user clicks Claim Task RRS feed

  • Question

  • I created a MOSS 2007 state-machine workflow and have my tasks assigned to SharePoint groups. Because of this, I get a Claim Task button automatically on the task form, which would allow the current user to 'claim' the task. When I click it, I get the dreaded "This task is currently locked by a running workflow and cannot be edited" message. One time, I actually had it work for me and the task was claimed, but then when I clicked on the "Release Task" button, I got the same error message.

    I don't have any custom code going on here: I just assign the task to a group when the task is created, then I get this error when the user clicks the Claim Task or Release Task buttons. I realize that the button may be calling the Alter Task method (just a guess), but I have no control over that as this is out-of-the-box functionality when a group is assigned to a task.

    Has anyone else ran into this? How can this be resolved? If there is no way of resolving it, can I disable/hide/remove the Claim Task and Release Task buttons?

    Monday, November 14, 2011 3:32 PM

Answers

  • I found out what my problem was. Just in case this happens to anyone else, here is what the problem was. Me.

    I said earlier that I didn't have any custom code, but actually I was mistaken. What I didn't realize was that when the Claim Task and Release Task buttons are clicked, they call the task's onTaskNameChanged_Invoked method. Up until this point, I had only expected that method to be called when the user clicked the Approve or Reject buttons that I had added manually to my InfoPath form.

    When those buttons are clicked, a form field called 'status' would have a value set to let me know the button was clicked. In other words, when the Approve button was clicked, status was set to 'approved', and when the Reject button was clicked, the status field was set to 'rejected'.

    In my onTaskNameChanged_Invoked method, I would then check the status field to see which button was clicked. This worked great so long as Approve or Reject was clicked - status always had a value because it was being set when those buttons were clicked.

    So when the Claim Task and Release Task buttons were clicked, the onTaskNameChanged_Invoked method was being called, status was not set, and therefore the code bombed when it attempted to reference the non-existent status field. I just love learning how SharePoint works under the covers!

    So all I did to resolve the issue was test for the status field's existence anywhere I planned on referencing it. Probably should have done that to begin with, but it never was a problem until I assigned SharePoint groups to my tasks, thus causing me to get the Claim Task and Release Task buttons on my task forms... Below was my test that resolved the issue.

    If Not onMyTaskChanged_AfterProperties.ExtendedProperties("status") Is Nothing Then
       do my other stuff, including reference the value of status...
    End If

    A final question I could ask is where does one go or what does on read to learn about the behind-the-scenes workings of SharePoint. I have often learned the hard way about how SharePoint works. Is it really just running into the problem, then debugging to figure it out? Or is there something I could have read beforehand that would have enabled me to avoid running into this? It seems there are tons of SharePoint gotchas that we run into and its a matter of working through how SharePoint works.

    • Marked as answer by D-Frag Thursday, November 17, 2011 10:06 PM
    Thursday, November 17, 2011 10:06 PM

All replies

  • Hello,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    Thanks,
    Qiao

    Wednesday, November 16, 2011 10:02 AM
    Moderator
  • Hi,

    Are you using the predefined workflows that are included in Microsoft Office SharePoint Server 2007, such as the Approval or Collect Feedback workflow. I hope in order to claim the task you are following the below steps :

    1. Open the Task list for the site, and then select All Tasks on the View menu to locate the workflow task assigned to your group.

     Note   If the workflow does not use the default Tasks list, the workflow task may not appear in the Tasks list. To locate your workflow task, go to the list or library where the workflow item is saved. Point to the item that you want, click the arrow that appears, and then click Workflows. On the Workflow Status page, under Running Workflows, click the name of the workflow in which you are a participant. Under Tasks, locate the workflow task.

    1. Point to the name of the task that you want to complete, click the arrow that appears, and then click Edit Item.
    2. Click Claim Task.

    The workflow reassigns the task from the group to you. You can now complete the task.

    Generally Locking of workflows is caused because of the WorkflowVersion not set to 1. Hence incase you are doing custom coding try following the altertask code as follows :

    using System;
    using Microsoft.SharePoint;
    using Microsoft.SharePoint.Workflow;
    using System.Collections;using System.Threading;
    namespace DevHoleDemo{
        public class WorkflowTask    {
            public static bool AlterTask(SPListItem task, Hashtable htData, bool fSynchronous, int attempts, int millisecondsTimeout)        { 
               if ((int)task[SPBuiltInFieldId.WorkflowVersion] != 1)            { 
                   SPList parentList = task.ParentList.ParentWeb.Lists[new Guid(task[SPBuiltInFieldId.WorkflowListId].ToString())]; 
                   SPListItem parentItem = parentList.Items.GetItemById((int)task[SPBuiltInFieldId.WorkflowItemId]); 
                   for (int i = 0; i < attempts; i++)                { 
                       SPWorkflow workflow = parentItem.Workflows[new Guid(task[SPBuiltInFieldId.WorkflowInstanceID].ToString())];       
                 if (!workflow.IsLocked)                    { 
                           task[SPBuiltInFieldId.WorkflowVersion] = 1;     
                       task.SystemUpdate(); 
                           break;   
                     }     
                   if (i != attempts - 1)  
                          Thread.Sleep(millisecondsTimeout);     
               }        
        }     
           return SPWorkflowTask.AlterTask(task, htData, fSynchronous); 
           } 
       }}
    
    

     


    Thanks, Ali Yasir
    Wednesday, November 16, 2011 1:00 PM
  • Good day to you. It appears Ali has given you a possible solution to the problem, however please let us know if it works out for you, or if you need further assistance.
    Regards,

    Jerad Plesuk
    Technical Support | SharePoint Technologies | Microsoft Corporation
    -----------------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights
    Wednesday, November 16, 2011 9:59 PM
  • I found out what my problem was. Just in case this happens to anyone else, here is what the problem was. Me.

    I said earlier that I didn't have any custom code, but actually I was mistaken. What I didn't realize was that when the Claim Task and Release Task buttons are clicked, they call the task's onTaskNameChanged_Invoked method. Up until this point, I had only expected that method to be called when the user clicked the Approve or Reject buttons that I had added manually to my InfoPath form.

    When those buttons are clicked, a form field called 'status' would have a value set to let me know the button was clicked. In other words, when the Approve button was clicked, status was set to 'approved', and when the Reject button was clicked, the status field was set to 'rejected'.

    In my onTaskNameChanged_Invoked method, I would then check the status field to see which button was clicked. This worked great so long as Approve or Reject was clicked - status always had a value because it was being set when those buttons were clicked.

    So when the Claim Task and Release Task buttons were clicked, the onTaskNameChanged_Invoked method was being called, status was not set, and therefore the code bombed when it attempted to reference the non-existent status field. I just love learning how SharePoint works under the covers!

    So all I did to resolve the issue was test for the status field's existence anywhere I planned on referencing it. Probably should have done that to begin with, but it never was a problem until I assigned SharePoint groups to my tasks, thus causing me to get the Claim Task and Release Task buttons on my task forms... Below was my test that resolved the issue.

    If Not onMyTaskChanged_AfterProperties.ExtendedProperties("status") Is Nothing Then
       do my other stuff, including reference the value of status...
    End If

    A final question I could ask is where does one go or what does on read to learn about the behind-the-scenes workings of SharePoint. I have often learned the hard way about how SharePoint works. Is it really just running into the problem, then debugging to figure it out? Or is there something I could have read beforehand that would have enabled me to avoid running into this? It seems there are tons of SharePoint gotchas that we run into and its a matter of working through how SharePoint works.

    • Marked as answer by D-Frag Thursday, November 17, 2011 10:06 PM
    Thursday, November 17, 2011 10:06 PM
  • Hi D-Frag,

    Great that you found the resolution to the issue. Your shared experience is a good info for all the readers.

    Regarding your question, I suppose practical experience is the only key to the learning. Moreover, msdn is another platform for the backup.

    Try referring blogs like robert shelton, http://secretsofsharepoint.com/cs/, ted pattison blogs etc.


    Thanks, Ali Yasir
    Friday, November 18, 2011 8:11 AM