In order to work around a KPI problem I wrote about here, I did some testing and discovered that KPI’s work against folders with meta data in the same way that they work against documents or list items. I proved it out by creating a new content type based on the folder content type and then added a few fields. I created some indicators and proved to myself that KPIs work as expected. This was welcome news. It’s not perfect, because the drill-down you get from the KPI against the folders is not exactly what you want. This isn’t too much a drawback in my case because 1) the end users don’t know any better and 2) the drill-down goes to a folder. They click the folder name and they are at the item. It’s two clicks instead of one, which isn’t the end of the world.
This flowed nicely with the work I was doing. I am creating a folder for every document that gets uploaded. This is done via an event receiver. As a result, it’s a piece of cake to keep the parent folder’s meta data in sync with the KPI-driven meta data from the file itself since the plumbing is already in place. This allows me to have my KPI’s and eat them too 🙂
I modified the event receiver to add the folder and then set this new folder’s content type to my custom KPI-friendly content type. This bit of code did the trick:
SPFolderCollection srcFolders = targetWeb.GetFolder("Documents").SubFolders; SPFolder addedFolder = srcFolders.Add(properties.ListItem.ID.ToString());
SPContentTypeId kpiCT = new SPContentTypeId("0x0120002A666CAA9176DC4AA8CBAA9DC6B4039F"); addedFolder.Item["Content Type ID"] = kpiCT; addedFolder.Item.Update();
To locate the actual Content Type ID, I accessed that content type via site settings and copy/pasted it from the URL as shown: