When Content Approval is required on a SharePoint List or Library, every item added to or updated in the lists needs to get approved by someone with proper permissions. Even if the user adding or updating the item has the appropriate permissions to approve an item, additional steps are required for the user to do this.

For the project I’m currently working on there’s a requirement to automatically approve items added to and updated in certain lists if the user adding or updating the item has permissions to approve the item. This prevents a user with such permissions having to perform additional steps (in different screens) to approve an item after adding or updating an item.

So, to make things easier and to provide this functionality I’ve implemented a SPItemEventReceiver which could be added to any list or library where this functionality is required. The event receiver code looks something like this:

In this case I’m using ItemUpdated to  set the approval status. Note that in Libraries, an EventReceiver like this should probably better be attached to the ItemCheckedIn event instead…

SharePoint Foundation’s SPList API now contain’s a method which can be used to retrieve a SPList’s “Related Fields”. This method returns a collection of SPRelatedFields representing all the Lookup Columns pointing to the SPList in question. This methods can be used as the basis for writing a useful extension method on SPList which retrieves a collection, specifically in this case a generic List<SPListItem>.

The Code Snippet below shows the code that will ultimately return the entire collection of ListItems that related to the SPListItem the method is called on:

Recently, I got a question from a developer who was wondering why the following statement caused a System.NullReferenceException:

SPContentType itemContentType = myCustomList.ContentTypes[SPBuiltInContentTypeId.Item];

The SPBuiltinContentTypeId Class contains static readonly fields representing all out-of-the-box ContentTypes in SharePoint Foundation (or WSS). The thing here is that when a Content Type is assigned to a List by using “Add from existing site content types” there actually is a new ContentType being generated under the hood. This newly generated ContentType actually inherits from the ContentType you selected to assign so it (initially) behaves exactly the same as it’s parent but it will have it’s own unique ID.

The SPBuiltInContentTypeId Class’ fields represent only the SPContentTypeIds of the ContentTypes typically instantiated at SiteCollection scope. Referencing a List-assigned version of the “same” ContentType won’t work using the overload of SPContentTypeCollection’s (SPList.ContentTypes) indexer taking a SPBuiltInContentTypeId because the ContentType has it’s own unique ID. In order to reference the List-scoped ContentType you should use one of the other two overloads of this class’ indexer instead. The first is taking an Int32 representing the index of a ContentType whithin the collection. However, for a more predictable result I’d recommend using the overload accepting a string representing a ContentType’s name:

SPContentType itemContentType = myCustomList.ContentTypes["Item"];

Code in Sandboxed Solutions can execute as soon the ”Microsoft SharePoint Foundation Sandboxed Code Service” is started on some server somewhere in your Farm. Sandboxed Solutions are hosted withing a specialized gallery within a SiteCollections’ top level website. The provisioning of this gallery is controlled by the GLOBAL SiteDefinition meaning each SiteCollection you create (whether this Sandboxed Code service is running or not) will contain this gallery and by this enable SiteCollection Administrators to Upload and Activate Sandboxed Solutions.  

So by default, when the Sandboxed Code Service is started, each SiteCollection whithin each WebApplication in your Farm is enabled to execute code in Sandboxed Solutions. Sometimes however you might want to disable the execution of code in Sandboxed Solutions on specific sitecollections while still allowing them to execute on other SiteCollections. There is no neat way to disable code execution from Sandboxed Solutions entirely on a specific SiteCollections. Maybe you’d expect to find a checkbox labeled “Disable Code Execution in Sandboxed Solutions”  somewhere under Site Collection Settings  in Central Admin but there isn’t.

This requirement could be achieved however by specifying a Quota Template and configure a specific SiteCollection to use it. Follow the steps below to specifiy a Quota Template effectively disabling Sandboxed code execution on a certain SiteCollection.

1. Open Central Administration

2. Browse to Application Management

3. Under Site Collections click “Specify Quota Templates”

4. Specify “Create a new quota template” and specify a name for it. Optionally you could start from an existing template here.

5. At the bottom of this page there’s a section with options to control Sandboxed Solutions called “Sandboxed Solutions With Code Limits”. Specify “0″ points in the TextBox labeled “Limit maximum usage per day to”

6. Click OK to save this template

7. Back on the Application Management Page, click “Configure Quotas and Locks”

8. On this Page, select the SiteCollection to apply the new quota template to

9. Under “Site Quota Information”, select the template just created

10. Click OK to save changes

Note that this will only block execution of custom code from within the Sandbox entirely. You are still able to provision declarative elements like List Instances for example to the Sandbox and use them without being blocked. I don’t think this is a problem however because otherwise the Site Collection administrator would have been able to create these kind of elements from within the browser or SharePoint designer anyway.

I was experiencing problems openening the “Datasheet View” of a SharePoint list. In my case, the issue was that ActiveX components where not allowed to run in the browser due to some security settings. While googling to find this solution I found some other things that might have caused the problem. Here they are:

• The browser is too old: IE 5.01 with SP2 is required
• The “Microsoft Office Access Web Datasheet Component” is not installed. This is included in Office 2007 and also available on the Office 2003 installation disc