SharePoint: How hide the field Title from a custom ContentType

Hiding the Title column in  a derived content type is not so easy.

I've not been able to do it declaratevily, for example the blog post [SharePoint 2010] Modifier les Fields hérités dans un content type personnalisé was very promising, by sadly didn't work (at least for me!).

So I've done it programmatively, and here is the code:

SPContentType myContentType = web.ContentTypes["MyContentTypeName"];
myContentType.FieldLinks["Title"].Hidden = true;
myContentType.Update(true, true);

Using Information Worker Demo with Oracle VM VirtualBox

This is my third article about using the preconfigured 2010 Information Worker Demonstration and Evaluation Virtual Machine (SP1).

I think I've found the final solution, or better, I've found a sequence of exceptional blog postings describing how to use it with Oracle VM VirtualBox in very deep detail:

SharePoint field security

SharePoint, in both 2007 and 2010 releases, doesn't implement field level security.

For sure hiding fields at the presentation level is not the correct solution: the want-to-be-hidden data is still available to the unwanted users through internal SharePoint pages, web-service call and all the cllient object model APIs, search, and so on.

Doing some researches on this topic I've found a very clever implementation in the following article: Column Level Security in SharePoint. This implementation is very clever, uses lookup fields to a protected tables and methods to retrieve data to authorized users only. The nice thing is that the final result is very nice, and it fit perfectly in the native SharePoint user interface (but of course above all it's really safe).

You can also download the sources from codeplex in the following address: SharePoint - Secure Field.

SharePoint 2010: permission policies

In a SharePoint it's possible to have many site collections inside a single web applications. If it could be difficult to manage permissions per each site collection, keeping them property synchronized could be a nightmare. Permission policies help to solve this topic, allowing to manage permissions for a subset of users or groups.

In fact, permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application.

To specify a permission policy:

  • you must be in the Farm Administrator security group on the computer running the Central Administration;
  • select the desired web application, and in the ribbon press the User Policy button, and then press the Add User button;
  • select the desired zone;
  • select specific users or groups;
  • select the desired permissions.

For anonymous users, once enabled them in the web application, it's possible to specify the following user policies:

  • None: no user policy defined;
  • Deny Write;
  • Deny All: it's like revoking access to anonymous users.

It's possible to find more information in the article Manage permission policies for a Web application (SharePoint Server 2010).

SharePoint 2010: creating custom Service Applications

SharePoint 2010 drops the old concept of SSP (SharePoint Service Providers) and introduces the concept of Service Applications.

They are a way of exposing WCF services leveraging all the benefits of the SharePoint platform, for example load-balancing and high-availability using multiple front ends.

Here are some links:

SharePoint: SPPersistedObject and hierarchical object store

SharePoint has the concept of SPPersistedObject and hierarchical object store.

The key concepts are:

  • inherit your configuration class from SPPersistedObject, give it a Guid and mark the needed fields (not properties) as Persisted;
  • hierarchical object store means that every object has a parent, so when the parent is deleted, all its children are deleted too;
  • every object has to have a unique name in the context of its parent;
  • it can be rather tricky to save collections of SPPersistedObject children, in this case the class SPAutoSerializingObject could be considered instead.

It's possible to find a very complete and detailed explanation in the article The skinny on SPPersistedObject and the Hierarchical Object Store in SharePoint 2010.

SharePoint: property bags

Property bags are used in SharePoint to store configuration values in the form of hash tables (key-value) at different levels: SPFarm, SPWebApplication, SPWeb and SPList.

They are simply used in the form of <my object>.Properties.

There is no default user interface to manipulate them, but it's possible to use SharePoint Designer 2010 (via Site Options | Parameters), SharePoint Manager 2010 and the more specific SharePoint Property Bag Settings 2010, or modify them by PowerShell too.

For other articles about them: