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/)
Hi Steve,
It’s funny that after 6 months since I asked the question on Sharepoint StackExchange and you submitted a DCR, Microsoft still hasn’t fixed it. It is a shame since it looks like this is a bug and also an easy change.
I currently need to break inheritance on all apps on the site in order to use SP 2013 workflows, which I really need for various business solutions.
Just uncovered this ‘gem’ myself. Seems to be the case in office365 too. It only seems to be an issue for manual workflows, ‘on change’ or ‘on new item’ fire OK when the user uploads.
After avoiding the Microsoft forums, I finally came across this blog and tried the Workaround #2 per Steve Lineberry: Addressed the issue immediately; Thank you for the insight Steve! (and yes, this issue is still a ‘thing’ 6 years later…)
A few notes:
1) I don’t believe this issue is caused by manual workflows; the culprit is the Initiation Form that is generated when a manual workflow starts (this form is optional);
2) I tried granting unique permissions to the ‘wfsvc’ library = Didn’t work;
3) I tried granting unique permissions directly to the ｢WFInitForm.aspx｣ my workflow used = Didn’t work;
4) Although I didn’t try it; Paul Keijzers came up with a solution by moving the Initiation Form to a place/location were users had the rights to access the form: https://sharepoint-specialist.nu/problem-with-workflow-initiation-form-pnp-solution-3ff246cad67;
5) To get the form to populate, my solution was to extend permissions on the site level (per Workaround #2); I found that providing List Permissions {Edit Items; View Items;} and Site Permissions {View Pages; Open;} was enough to get the form to load; users didn’t need the ability to add/delete lists/documents that is attached to ｢Contribute｣. I created a new permissions level just for this issue (https://｢DOMAIN_NAME｣.sharepoint.com/_layouts/15/role.aspx)
– Kenny Lemens; P.E.
Great work – I saw elsewhere that the bug should have been ironed out by now. Can you verify that?
BR
Morten
Yea, my co-worker confirmed that it’s been fixed in the October 2015 CU. Let me know if that doesn’t work for you. Thanks.
Hi Steve
Ok it should be fixed in the October release? Because we have the september release (And no October release for us to install) and it still does not seem to Work 🙁
My use case is slightly different than yours, but it sounds very palusible that the root cause for my error is the same.
I’m trying to start a workflow by calling the rest API, and everything works perfectly as long as the user has at least contribute permission on the entire site.
BR
Morten
Hmm I’ve just checked, it would seem we did try to install the CU from October, but something went wrong. Or at least the CU wasn’t installed.
BR
Morten
I have run into a very similar issue to this. In my case, I am in an O365 tenant. I have a Timecard form library and 2013 workflow. In the 2013 workflow, I call three different SharePoint 2010 workflows at different times throughout the Timesheet approval process for limiting who has access to different timesheets. These SP2010 workflows only include an impersonation step. When I set the Created By or any other user to Read, I get this error. But if I give them Contribute or Edit permission, then the workflow runs. The issue I have is that I don’t want users to have Contribute/Edit after they have submitted their timesheet – only Read. Another co-worker is running this same sort of workflow on a SP List in the same tenant and that workflow runs just fine. Any thoughts on what I should do?
How does one actually report bugs like this to Microsoft? I often run into bugs with Microsoft products and just don’t know where to turn. Reporting issues on Microsoft Connect for example seems like a complete waste of time. How do Microsoft customers actually report bugs?