SummaryLinkWebPart: 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’).

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.ThrowIfSaveWouldFail() +24319257
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.LoadWebParts() +146
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.

Advertisements

About Bernado

Based in Australia, I am a freelance SharePoint and Dynamics CRM developer. I love developing innovative solutions that address business and everyday problems. Feel free to contact me if you think I can help you with your SharePoint or CRM implementation.
This entry was posted in SharePoint 2010, SummaryLinkWebPart. Bookmark the permalink.

3 Responses to SummaryLinkWebPart: 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’).

  1. Charles E. says:

    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!!!

    • Bernado says:

      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?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s