Many scenarios in SharePoint 2010 require you to create indexes on lists – e.g. enforcing unique values, CAML joins, and referential integrity. I was writing some code yesterday that needed an index and I wasn’t able to find a sample – so I figured I’d put up a quick post.
Before you get started, understand that you can only index certain field types and that compound indexes are even more restricted. See this page for the types of indexable fields: Metadata Navigation and Filtering.
Here is the sample c# code. (list is an instance of SPList for the list that will be indexed)
Single Column Index
SPField title = list.Fields["Title"];
title.Indexed = true;
SPField createdBy = list.Fields["Created By"];
createdBy.Indexed = true;
SPField created = list.Fields["Created"];
created.Indexed = true;
Author: Doug Ware
SharePoint 2010 includes a number of new services to allow interoperability with other systems and to make it easy to create rich Internet applications. Among these is SharePoint’s ODATA implementation provided by the ListData.svc service. Overall, I think the REST is an awesome lightweight alternative to formal SOAP. Unfortunately, the implementation SharePoint provides opens a large attack surface that makes it very easy to discover the information for every user in a site.
Unlike alternative interoperability services like the traditional SOAP based services and the SharePoint Client Object Model, you must access the ListData.svc with an account that has Browse User Information permission. Consider a scenario where you want to allow a system external to your organization to read and write items in a site. You can create a permission level that allows this interaction by granting:
- Add Items
- Edit Items
- Delete Items
- View Items
- Use Remote Interfaces
An account with this set of permissions allows the use of the Client Object Model and some of the SOAP services to the external system to read and write list items and documents. However, the account can’t browse the site’s contents because it hasn’t got View Pages permission, nor can the account access information about the other accounts with access to the site.
SharePoint’s WCF Services implementation, ListData.svc, will not work with the above set of permissions. To make it work, you must grant Browse User Information permission.
There are probably many scenarios where you can justify this, but I personally think that a data interchange technology that reveals the accounts with access to the data store is best avoided considering that the alternatives don’t have this flaw.
I hope this is fixed soon, because I’d love to use REST with SharePoint and I will as soon as Microsoft makes it possible to harden SharePoint REST (OData) security. At the moment I think it would be irresponsible to do so in most of the scenarios where REST is attractive.
Author: Doug Ware
Earlier this week I was putting together a demo for an upcoming user group meeting about lists and content types where I was creating a new content type that would support some contact information and some calendaring information. The content type is used in two different lists. One is a contact list that can be connected to Outlook as a contact view and the other is a calendar that can be connected to Outlook as a calendar.
I started out by creating a new content type based on Contact, added a couple of custom site columns, and then attempted to add Start Date, End Date, and Location from the Event contact type. But, to my surprise, they were not listed!
After a little investigation I realized that the Event content type is in the _Hidden group! Now, I don’t know why this is, but I suspect the reason rhymes with ‘hug’. First, because it doesn’t make any sense and I couldn’t find any explanation of why this might be on the web. The second is because the WSS SDK says that it is part of the List Content Types group, not the _Hidden group. Whatever the reason, I needed those fields!
Fortunately, you can put the Event content type into the List Content Types Group pretty easily via the UI without resorting to writing any code or altering the feature or site definitions.
Create a new Calendar list by choosing Create from the Site Actions menu.
and choosing Calendar
- Fill out the form and click OK
- Open the list settings by choosing List Settings from the Settings menu.
By default, Lists do not allow management of the content types they are based on. Which is a double edged sword because while it makes things easier for the user it also increases the chances that someone will edit a field in a list, like a calculation, that later gets stomped by an update to the content type. But I digress… To access the Event content type we need to configure the list to allow management of content types. Click advanced settings under General Settings.
- On the Advanced Settings page select Yes for ‘Allow management of content types?’ and click OK.
A new section is now displayed on the list settings page for the content types used by the list. To access the Event type click the Event link.
On the subsequent page click the Event link beside the Parent: label.
- On the Content Type Information Screen follow the Name, description, and group link
Change the Group to List Content Types and click OK
That’s it. Now you can get at the event columns when creating your own content types and choose Event as the parent if you want to create new Site Content Types based on Event.
If you want to rehide the type, simply edit it from the Site Content Type gallery on Site Settings and assign it to the _Hidden group.
Author: Doug Ware
Powering SharePoint customizations…