I have a Discussion list. I have 3 classes of users:

Owners Contributors Viewers

The list is configured to allow Contributors Add/Edit/Delete permissions, however in the Advanced Settings for the list, the Item Level permissions are set to "Only their own" (that is users can Edit/Delete only their own Discussions/Replies).

I see that in this scenario the OOB SharePoint UI doesn't security trim the Discussions/Replies when displayed in OOB SharePoint list views and view/edit forms. However, when I attempt to take the save the Edit/Delete action in the OOB SharePoint UI, I get redirected to the Access Denied page.

I have attempted to build custom UI on top of the Discussion list (think custom web parts/usercontrols/etc.). I have code to check to see if a user can edit the item by using code similar to the following:

lbtnDelete.Visible = listItem.DoesUserHavePermissions(SPBasePermissions.DeleteListItems);

This doesn't appear to be checking the permissions at the level of detail needed to determine if the user should be able to actually edit the item or not (i.e. by checking the SPList's WriteSecurity (1 = Any item, 2 = Only their own, 4 = None).

What is the proper way to confirm a user actually has Edit/Delete permissions, taking into account the Item Level Permissions?

  • I have something like this, but it doesn't account for folks that might have "Full Permissions": if (listItem.DoesUserHavePermissions(perms)) { if (parentList.WriteSecurity == 4) //None hasPerms = false; else if (parentList.WriteSecurity == 2) //Only their own { if (listItemCreatedBy.LoginName == SPContext.Current.Web.CurrentUser.LoginName) hasPerms = true; else hasPerms = false; } else – Brian May 18 '10 at 1:25
  • Curious if 2010 has addressed this in anyway...If I had the time! – Brian May 19 '10 at 12:55

I came up with the following code that seems to meet my needs. Because I don't know all the details of what checks actually get performed when SPListItem.Update() or SPListItem.Delete() get called (the details are not available from Reflector), I cannot say whether this will work for all scenarios, but it does for me where my permissions are rather simple:

A user has "Read Only" permissions, or a user has "Contribute" permissions to the list, or a user has "Full Control" to the list.

Here is a set of Extension methods (requires .NET 3.5). These can easily be converted to private/public helpers:

public static bool DoesUserHaveEditOrDeletePermissions(this SPListItem listItem, SPUser listItemCreatedBy, SPBasePermissions perms)
            if (perms != SPBasePermissions.EditListItems && perms != SPBasePermissions.DeleteListItems)
                throw new ArgumentException("This method only supports the EditListItems and DeleteListItems permissions.", "perms");

            bool hasPerms = false;

            SPList parentList = listItem.ParentList;

            //NOTE: this is an Extension method, not an OOB SPList method (see below)    
            if (parentList.DoesUserHaveFullControl())
                hasPerms = true;
                if (listItem.DoesUserHavePermissions(perms))
                    if (parentList.WriteSecurity == 4) //None
                        hasPerms = false;
                    else if (parentList.WriteSecurity == 2) //Only their own
                        if (listItemCreatedBy.LoginName == SPContext.Current.Web.CurrentUser.LoginName)
                            hasPerms = true;
                        hasPerms = true;

            return hasPerms;

        public static bool DoesUserHaveFullControl(this SPList list)
            SPRoleDefinitionBindingCollection roles = list.AllRolesForCurrentUser;
            for (int i = 0; i < roles.Count; i++)
                SPRoleDefinition item = roles[i];
                if (item.BasePermissions == SPBasePermissions.FullMask)
                    return true;

            return false;
  • Note: may want to modify the comparison check for listItemCreatedBy.LoginName == SPContext.Current.Web.CurrentUser.LoginName to be case IN-sensitive. – Brian May 19 '10 at 12:53

As you've noticed DoesUserHavePermissions doesn't account for other factors that might affect their ability to use the list

Things it does account for:

  • role assignments
  • policy
  • site collection administrator status
  • anonymous access

Things it does not account for:

  • SPList.AllowEveryoneViewItems
  • SPList.WriteSecurity (edit their own etc)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.