Recently, after we finished migrating our large external farm from SharePoint 2010 to SharePoint 2013, I started hearing complaints that some user’s could not manually start workflows. They would either get a 403 Forbidden or get the “Sorry, you don’t have access to this page” message.
The stack trace on the back end produced the following:
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)
Figuring out the problem just took a little investigation. I recently used this as a Demo for a SharePoint session I did recently at my local SharePoint Saturday. From that session I have a video of the issue and how I determined the cause. Skip to about 2:15 for the start of the issue and investigation. Click here to see the video
So basically the new SharePoint 2013 Workflow Manager is checking for Contribute access at the Site (SPWeb) scope when determining if someone should see the list of workflows for a list (see first line of the method in the code below).
// 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);
}
So in our scenario, our users had read access to the site but contribute access on the list. This should allow them to start the workflow and it did in SP 2010. I currently have a Design Change Request (DCR) open with MS regarding this issue so hopefully it will be fixed soon. Once I hear more, I will update this post. In the meantime there seems to be two workarounds.
Workaround 1: Earlier in the code I determined that if you DON’T setup and connect a SharePoint 2013 Workflow Manager to the farm, then this code will never run and thus it will work just like it did in SP 2010. Of course the issue with this workaround is you can’t have any SP 2013 workflows.
Workaround 2: Basically give everyone that needs to manually start workflows 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.
We ended up implementing the second workaround above which sucks for my users. I am hoping this is fixed soon as I have also seen other people complaining about it (http://sharepoint.stackexchange.com/questions/115311/manually-start-sharepoint-2010-workflow-in-sharepoint-2013-farm/)