[update: a quick review by one of our SDETs resulted in some good suggestions to make the code below more useable, and I’ve added them to the code below (1. Using GetByType to return the Role Definition rather than specifying the name as a string, thereby working in localized versions other than en-us and 2. checking for unique permissions prior to adding the Role Assignment to the List Item, and breaking permission inheritance if needed – in the case of inherited permissions, the call would otherwise fail). Thanks, Eric!]
[another quick update: be aware that item-level permissions cannot be set/modified via any out-of-the-box Web Service. The Permissions Web Service (permissions.asmx) can be used to work with permissions on sites or lists, but not items. I hope to create another post sometime relatively soon on creating custom Web Services in WSS 3.0/MOSS 2007, and perhaps I’ll use the code below in the context of a custom web service for that post as well.]
One of the cool new things in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 (get your public beta here) — and make no mistake, there are a lot of cool things to go around in these products — is fine-grained (item-level) security. This was a big big customer wish from the current “v2” versions of the products, and it’s fantastic to see it in the products now. The whole permissions object model has changed (for the better) as a result, and the product team has built in some great flexibility when working with role-based item-level security via the object model. I’ve created a quick sample that shows how to set permissions using the various new OM objects and methodologies, and have included it below as an example that can be expanded to other “permissionable” objects within WSS/MOSS as well.
In this sample, I’m going set permissions on a individual SPListItem. I’ll create or access a Role Assignment (which essentially represents the user), bind a Role Definition to the Assignment (such as "Full Control", "Contribute," etc.), then add the Role Assignment to the object's RoleAssignments collection. Here’s the code (I’m using a simple C# console app…assume a reference to Microsoft.Sharepoint.dll):
static void Main(string args)
static void SetListItemPerms()
//Get SPWeb object
//Get Role Definition from SPWeb
SPRoleDefinition RoleDefinition = Web.RoleDefinitions.GetByType(SPRoleType.Administrator); //or whichever SPRoleType you choose
SPList List = Web.Lists["<list name>"]; //e.g., "Announcements"
SPListItem ListItem = List.Items;
//Create new Role Assignment
//Add Role Definition to Role Assignment's Role Definition Bindings
SPRoleAssignment RoleAssignment = new SPRoleAssignment("<login name>", //e.g., "MYDOMAIN\UserA"
"<email address>", //e.g., "email@example.com"
"<display name>", //e.g., "User A"
"<notes>"); //e.g., "Here are some notes."
//Check for permission inheritance, and break if necessary
ListItem.BreakRoleInheritance(true); //pass true to copy role assignments from parent, false to start from scratch
//Add Role Assignment to SPListItem's Role Assignment Collection
And that’s that! The user that I specified when creating my new Role Assignment will have Full Control of this single List Item only. 🙂