Normal users (read-only) of our SharePoint site start receiving this error when visiting a content page:
Access Denied saving Web Part properties: either the Web Part is embedded directly in the page, or you do not have sufficient permissions to save properties (Web Part ‘[web part name]’).
The full stack is:
[WebPartPageUserException: Access Denied saving Web Part properties: either the Web Part is embedded directly in the page, or you do not have sufficient permissions to save properties (Web Part ‘Summary Links’).]
Microsoft.SharePoint.WebPartPages.WebPart.SetSavePropertiesInternal(Boolean dirty) +66
Microsoft.SharePoint.WebPartPages.WebPart.set_SaveProperties(Boolean value) +24296479
Microsoft.SharePoint.Publishing.WebControls.SummaryLinkWebPart.OnInit(EventArgs e) +122
System.Web.UI.Control.InitRecursive(Control namingContainer) +143
System.Web.UI.Control.AddedControl(Control control, Int32 index) +271
System.Web.UI.WebControls.WebParts.WebPartManagerControlCollection.AddWebPartHelper(WebPart webPart) +305
System.Web.UI.WebControls.WebParts.WebPartManagerControlCollection.AddWebPart(WebPart webPart) +1933374
System.Web.UI.WebControls.WebParts.WebPartManagerInternals.AddWebPart(WebPart webPart) +63
Microsoft.SharePoint.WebPartPages.SPWebPartManager.AddWebPartWithRetry(WebPart webPart) +746
Microsoft.SharePoint.WebPartPages.SPWebPartManager.CreateWebPartsFromRowSetData(Boolean onlyInitializeClosedWebParts) +7123
Microsoft.SharePoint.WebPartPages.SPWebPartManager.OnPageInitComplete(Object sender, EventArgs e) +288
System.EventHandler.Invoke(Object sender, EventArgs e) +0
System.Web.UI.Page.OnInitComplete(EventArgs e) +11058238
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1674
The error appeared random and occurred for different pages. Sometime for the same page, the error would go away then come back later.
As it turns out, other people are experiencing the same issue: http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/d86e22b3-d929-48b1-9e4a-166a275365d1/. The error appeared random because it would go away when an admin user visits the page, and sometime came back at a later stage.
These errors are caused by the OOTB SummaryLinkWebPart. Using dotPeek to look at the code I was able to figure out what’s going on.
Internally the SummaryLinkWebPart stores the URL of the links that have been added to it. When the web part loads, it compares the stored URLs with the actual current URL of the links. If there are differences, it will update itself. It does this even for normal users that have read-only access, and hence the error occurs. When an admin user visits the page, the web part is able to successfully update its data. The stored URLs and the actual current URL of the links are in sync, and hence the page starts working again for read-only users… until someone updates the URL of one of the links that have been added to the SummaryLinkWebPart.
I have tested this with the July 2012 CU and the issue still exists.
Please let me know if you have found a fix for this somewhere.
Thank you so much for this explanation! We’ve been facing the same issue intermittently for over a year, and could never get a handle on it because the Admin users would end up ‘fixing’ the problem unintentionally. Brilliant!!!
here is a thread about the same issue and how it was resolved.
Thanks for the update Reza. I think it’s pretty poor for MS to say that the problem “is by design” though. Surely the web part could elevate permission and perform the update as an admin account right?