Hide the "View All Site Content" Quick Launch Link

To hide this link from all but those users with full control over a WSS site, open the site master page in SharePoint Designer and find the SPSecurityTrimmedControl element that contains a div with class ms-quicklaunchheader. The quickest route to this is to view the page in split view, and click on the "View All Site Content" link in the design pane.

The PermissionsString attribute of the SPSecurityTrimmedControl element determines what users can view this content. Change the value of this attribute to ManageWeb and only those users with rights to perform all admin tasks on the site will then be able to see the link on all pages in the site.

See this page for a list of all the possible permission string values.

A Tool to Help with CAS Policies

When adding Code Access Security policies to a manifest file in a SharePoint feature, determining which permissions to apply can be a hit and miss affair. Add some permissions, activate the feature and read the SecurityException to get an idea of what else is needed.

But help is already on your development machine, in the guise of PERMCALC (official known as the "Minimum Grant Set Determination tool"), a visual studio command line tool that is run from the Visual Studio Command window.

This tool is run against one or more assemblies, and generates an XML file listing the "estimated" permissions that must be granted to access that assembly. It attempts to trace all code paths through the named assembly, and through the libraries called by the assembly. So even if it doesn't give a comprehensive view, it can be a useful check before you start debugging those CAS issues.

An overview of the tool is available on the Microsoft site..

SPGridView Requests FileIOPermission When Added to a Web Part

I have been struggling with the SPGridView causing a security exception in a custom web part. Exploring the code with reflector reveals that when the SPGridView loads it tries to register a JavaScript file from the Templates\layouts folder in the 12 hive, and this process involves a call to the MakeBrowserCacheSafeLayoutsUrl method. That method attempts to create a unique file name for the JavaScript file. This requires that the JavaScript file is opened and read, therefore needing FileIOPermissions. If the web part is not explicitly being granted FileIOPermission in CAS, then the rendering fails.

I added the following to the manifest file that configures the CAS settings for my custom web part:

<ipermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" read="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12;$AppDir$" write="$AppDir$" append="$AppDir$" pathdiscovery="$AppDir$">

Must admit to not being happy with hard-coding the path, but it got the web part working!

If you are wondering about the $AppDir$ parameter, I quote "it refers to the initial folder the application points to, and any subfolders". Not sure what these are for SharePoint - I tried using just $AppDir$ for the Read attribute but that did not supply the necessary access in this case (hence the hard-coded path).

Removing User Permissions From a List Item

Programmatically modifying the item-level permissions in a list involves manipulation of the Role Assignments collection for that item.

This example shows how to remove a specific role definition from each of the members of a user collection:
   /// <summary>
        /// Remove a role definition from each of the members of a user collection for a list item
        /// </summary>
        /// <param name="item">The List Item</param>
        /// <param name="userVals">The collection of users who are to have the role definition removed</param>
        /// <param name="def">The role definition to remove</param>
        internal static void RemoveRoleDefinitionFromUsers(SPListItem item, SPFieldUserValueCollection userVals, SPRoleDefinition def)
        {
            if (userVals != null)
            {
                foreach (SPFieldUserValue userVal in userVals)
                {
                    SPUser user = userVal.User;
                    SPRoleAssignment role = item.RoleAssignments.GetAssignmentByPrincipal((SPPrincipal)user);
                    if (role != null)
                    {
                        if (role.RoleDefinitionBindings.Contains(def))
                        {
                            role.RoleDefinitionBindings.Remove(def);
                            role.Update();
                            item.SystemUpdate(false);
                        }
                    }
                }
            }
        }

Dependencies in Custom SharePoint Permissions

An event handler I have written applies item-level permissions to modified list items - specific users are granted custom permissions.

This was working fine until I enabled versioning on the list manipulated by the handler. After making that change I noticed that the specific users were now seeing the access denied page in SharePoint when attempting to view items with the managed permissions.

The code was assigning SPBasePermissions.EditListItems and SPBasePermissions.ViewListItems rights for the users. After experimenting in the Edit Permissions Level administrative page in the site settings, I noticed that checking certain boxes caused other boxes to be checked - there are clearly some dependencies behind the scenes that should be applied when assigning custom permissions.

The outcome of the experimenting was that with versioning enabled on the list, the view versions permissions was required. Edit rights on an item will be granted to a user by applying the following set of SPBasePermissions to the role definition:

SPBasePermissions.EditListItems SPBasePermissions.ViewListItems SPBasePermissions.OpenItems SPBasePermissions.ViewVersions SPBasePermissions.ViewPages SPBasePermissions.Open

Viewing rights are granted with the same set, minus the EditListItems member.