Yaroslav Pentsarskyy's SharePoint and .NET adventures

For about some time I have been working on a SharePoint 2010 solution where I need to heavily customize SharePoint EditItem form. Not a big deal, I created a custom rendering template. I also have a custom Save button that has to perform some additional field setting. One thing that my SPList has to have is a WriteSecurity=2 . WriteSecurity is a new property in SharePoint 2010 allowing your users to create new items in a list but edit ONLY their own.

In my solution I had to respect that notion but I also had to allow administrative users to be able to overwrite this restriction.

So in efforts to do that I created my own custom Save button and overwrote it`s SaveItem() function and elevated permissions on base.SaveItem()

Well, SharePoint didn`t like that idea. The problem was with the fact that item context was transfered from the parent SPWeb which already was opened under the context of the existing user (non-admin) and my list item was convinced that there was no elevation done at the time of saving the item.

One solution that I found working is to create new SPSite, SPWeb objects and get a hold of the list. Once I have an item in question I would pass base.ItemContext.ListItem to it and all of the user entered data would get transfered the new SPListItem object that was now under my control. My save operation succeeded.

Here is how my code looked like:

protected override bool SaveItem()

{

bool saveResult = false;

SPSecurity.RunWithElevatedPrivileges(delegate

{

SPSite site = new SPSite(Constants.LocalSiteCollection);

SPWeb web = site.OpenWeb();

SPList list = web.Lists["MyList"];

web.AllowUnsafeUpdates = true;

SPListItem item = base.ItemContext.ListItem;

/// …. other updates to SPListItem …

item.SystemUpdate();

saveResult = true;

base.RedirectUrl = SPContext.Current.Web.Url;

web.Dispose();

site.Dispose();

});

return saveResult;

}

Enjoy!

sharepoint, sharepoint 2010 ItemContext, RunWithElevatedPrivileges, SaveItem, sharepoint 2010, splist, splistitem, WriteSecurity

Here is the scenario: I have a site provisioning script that creates my publishing site structure; I use a feature that provisions Default page content based on a generic layout and definition. Since my generic feature doesn`t assign title of the page – my pages are title-less and that doesn`t look good when the site is provisioned.

What I need in this case is a utility feature that will set my Default.aspx to have the title property equal to the SPWeb title. However, I don`t want to perform such a modification and leave all sorts of things in history like Modified name changed and time as well as create several versions for check in and check outs required to make a property change.

What I need is a discrete feature that will make the change but does`nt polume my metadata. I will use SPListItem.SystemUpdate();

Here is a piece of my code where I set the page title and won`t need to do a checkout and check in and modify metadata:

// web here is received from the feature properties

PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(web);

SPFile defaultPage = pubWeb.DefaultPage;

//defaultPage.CheckOut();

//defaultPage.Update();

defaultPage.Item["Title"] = web.Title;

defaultPage.Item.SystemUpdate();

PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(web);

SPFile defaultPage = pubWeb.DefaultPage;

defaultPage.Item["Title"] = web.Title;

defaultPage.Item.SystemUpdate();

Simple, but useful, hopefully you find it like that as well!

MOSS, sharepoint splistitem, systemupdate