Is it just my SharePoint 2013 environment or does anyone else experience the follow issue?

A SharePoint 2010 workflow attached to a SharePoint 2013 list cannot be started manually for individual items in the list unless the user has at least Contribute permissions to the site where the list is located.

Note the following:

  • the Workflow.aspx page of a list item (where the workflows can be manually started and where the lists of running and completed workflows are) cannot be accessed (Access Denied) if the user doesn't have at least Contribute permissions to the site.
  • this happens to all users who do not have at least Contribute permissions to the site.
  • the list has unique permissions and users have at least Contribute permissions to it.
  • the workflow history of a workflow that ran for an item in the list can be accessed by any user with access to the list, regardless of the permissions they have to the site.
  • the workflows cannot be started manually by a user with Full Control on the list unless he has at least Contribute access to the site.
  • if the site is on a site collection using the 2010 experience version, then the problem doesn't exist. As long as the user has at least Contribute permissions to the list item, he can access the Workflow.aspx page and manually start workflows.
  • the message that the user sees when trying to access the Workflow.aspx (to manually start workflows) is: "Sorry, you don't have access to this page."


Have you experienced this? If yes, how did you solve the problem?

up vote 2 down vote accepted

Yes, this is the case. I currently have a design change request open with MS to fix this issue and it does sound like that it is going to be fixed in a future CU.

If you reflector the code and take a look, you can see exactly where it is checking for contribute access at the site (SPWeb) scope.

// Microsoft.SharePoint.WorkflowServices.StoreSubscriptionService
public override WorkflowSubscriptionCollection EnumerateSubscriptionsByEventSource(Guid eventSourceId)
{
    this.context.Web.CheckPermissions(SPBasePermissions.EditListItems);
    WorkflowStore workflowStore = new WorkflowStore(this.context.Web);
    eventSourceId = StoreSubscriptionService.ConvertToGuidToken(eventSourceId, this.context.Web);
    WorkflowFile[] files = workflowStore.QueryWithGuid("0x0100AA27A923036E459D9EF0D18BBD0B9587", StoragePublishState.Unchanged, "WSEventSourceGUID", eventSourceId);
    return this.ConvertToWorkflowSubscriptionCollection(files);
}

Here is the stack trace:

Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(HttpContext context) at Microsoft.SharePoint.Utilities.SPUtility.HandleAccessDenied(Exception ex) at Microsoft.SharePoint.SPSecurableObject.CheckPermissions(SPBasePermissions permissionMask) at Microsoft.SharePoint.WorkflowServices.StoreSubscriptionService.EnumerateSubscriptionsByEventSource(Guid eventSourceId) at Microsoft.SharePoint.WorkflowServices.ApplicationPages.WorkflowPage.ConstructStartArray() at Microsoft.SharePoint.WorkflowServices.ApplicationPages.WorkflowPage.OnLoad(EventArgs e)

EDIT: Oops, I forgot to say what we did for the temporary workaround. Now this workaround sucks, but you basically give everyone contribute access to the site, and then break inheritance to all lists and libraries where the user DOESN'T need contribute access and remove their contribute access.

EDIT 2: For more details on how I figured this out and the workarounds, I have blogged about it here: http://steve.thelineberrys.com/unable-to-manually-start-workflows/

  • Thanks for the reply. It helps to know it is not me, but SharePoint. I thought about the exact same workaround, but it SUCKS so bad. I will be waiting for the CU as starting workflows manually is not really necessary for my solutions, and where it is, the user has at least Contribute access to the site. Where did you submit your design change request to Microsoft? Is it public to follow it? – Mihail Popa Sep 17 '14 at 9:29
  • I submitted it through premier support. No, it's not public. – Steve Lineberry Sep 17 '14 at 11:00
  • 1
    Oh, btw, the other workaround is to NOT have SharePoint 2013 workflows enabled on the farm. This way it's never checking for any SP 2013 workflows and thus it doesn't do the contribute permission check on the site (spweb). – Steve Lineberry Sep 17 '14 at 11:03
  • 1
    The latest update I received was this fix is currently in testing and planned for an April 2015 CU release. – Steve Lineberry Mar 17 '15 at 14:18
  • 1
    Superb, @SteveLineberry . Thanks for letting us know. I hope the fix will be included in the April 2015 CU as they say. – Mihail Popa Apr 1 '15 at 15:19

Edit: It would seem we're not running September CU afterall. Sorry for the confusion!

I have tried with the latests September CU update, and I cannot get it to work either. (Sorry I cannot comment yet)

  • Suggest not to remove as this contributes to the answer. – Paul Strupeikis Oct 30 '15 at 11:14

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.