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

In my last article you’ve seen how to set item level permissions on a list items for both read and write access. In this article I wanted to dive into 2 few more functions that you see on Advanced Settings page of the list, those are: disabling list item attachments, Specify whether the “New Folder” command is available, Specify whether this list should be visible in search results.

The last option that allows you to exclude list from search results is particularly great. Not that this option will overwrite permissions to the list; in other words users that have no access to the list won’t see it anyway. It’s still nice to be able to exclude list from crawl even if users have read only access to improve the cleniness of search results.

As yesterday, I will get a hold of the list using the explicit specification – so that you can run it in a console application project:

SPSite site = new SPSite(”http://localhost”);
SPList userList = site.OpenWeb().Lists["MyList"];

// Specify whether this list should be visible in search results
userList.NoCrawl = true;

// disabling list item attachments
userList.EnableAttachments = false;

// Specify whether the “New Folder” command is available
userList.EnableFolderCreation = false;
site.Dispose();

Hopefully this was clear. You will probably end up running this in a feature receiver or in some sort of a portal configuration script or application.

Enjoy!

sharepoint, sharepoint 2010 disable attachments, disable folder creation, EnableAttachments, NoCrawl, sharepoint 2010, splist

In SharePoint 2010 you get an ability to set item level permissions on items in a list or library, here is how UI in Advanced Settings of the list looks like:

If you’re defining your site through a schema or definition you probably want to know how all of those settings are set through the code, and here’s how:

First, the Read Access  option is toggled Read all items or Read items that were … to set that you will write something like this:

SPList list = SPContext.Current.Web.Lists["MyList"];
list.ReadSecurity = 1;

The value of ReadSecurity will be either 1 or 2 as per msdn article.

Now the second option that will determine permissions to edit items will look somethig like this:

SPList list = SPContext.Current.Web.Lists["MyList"];
list.WriteSecurity= 1;

Here the value will be 1, 2 or 4 depending on the option that you can check out here at msdn.

Very usefull two options that back in MOSS days I had to write event receiver for, now available out of the box!

sharepoint, sharepoint 2010 Item-level Permissions, ReadSecurity, sharepoint 2010, splist, WriteSecurity