6

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?

Improve this question

2 Answers 2

Reset to default
2

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/

Improve this answer
10
  • 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
    Commented Sep 17, 2014 at 9:29
  • I submitted it through premier support. No, it's not public.
    – Steve Lineberry
    Commented Sep 17, 2014 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
    Commented Sep 17, 2014 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
    Commented Mar 17, 2015 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
    Commented Apr 1, 2015 at 15:19
0

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)

Improve this answer
1
  • Suggest not to remove as this contributes to the answer.
    – Paul Strupeikis
    Commented Oct 30, 2015 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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