The Workflow History list content type, which can be found in the hidden Workflow History list, is unusual in that it has no parent content type. Normally, in a loop such as
foreach(SPContentType listType in list.ContentTypes)
listType.Parent is a valid content type which is a site content type, but it is null for the Workflow History list content type on the Workflow History list.
Note: The Workflow History list being hidden, one cannot navigate to it via View All Site Content. But if one knows its GUID, one can navigate to it via ~/_layouts/listedit.aspx?List=%7B123456%7D, where 123456 stands for the actual GUID.
Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
Background
I wanted to quickly make a copy of a publishing site collection that I had been working on (for a colleague), and did the following.
First, as stated above, the site I wanted a copy of was a SP Publishing Site. I knew from preious experience that one is unable to save a publishing site as a site template (it's not supported by Microsoft for good (although unfortunate) reason).
That being said, I moved forward with an unsupported workaround (FYI, this was in a development environment). I deactivated both the Site Collection and Site/Web Publishing Features ([Office SharePoint Server Publishing Infrastructure], and [Office SharePoint Server Publishing] respectively). Once deactivated I had the menu option "Save site as template" available to me (under Site Actions >> Look and Feel ), and was able to successfully save the site as a site template.
Upon my attempt to reactivate the site collection publishing feature (that I had deactivated in the previous step) I ran into the following exception:
Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
Solution
To resolve this problem I ran the following stsadm commands (replacing "URL" with the actual URL of the Site Collection) - which I found on a Technet forum, posted by Chris Winebarger.
stsadm -o activatefeature -filename publishing\feature.xml -url http://URL -force
stsadm -o activatefeature -filename publishingresources\feature.xml -url http://URL -force
stsadm -o activatefeature -filename publishingSite\feature.xml -url http://URL -force
stsadm -o activatefeature -filename publishingweb\feature.xml -url http://URL -force
stsadm -o activatefeature -filename publishinglayouts\feature.xml -url http://URL -force
stsadm -o activatefeature -filename navigation\feature.xml -url http://URL -force
All was then back to normal.
Reference:
Chris Winebarger's post on a SharePoint Technet Forum
http://social.technet.microsoft.com/Forums/en/sharepointadmin/thread/13da092f-8c6f-44c8-a99b-140e277c8d55
Let me first start by saying the script we're providing is adapted from script posted by Ricky Spears (http://sharepointsolutions.blogspot.com/2007/09/make-selected-links-in-links-list-open.html)
OOB Sharepoint Link Lists do not provide you the option to have a links open in a new window. The following steps and script will allow for such functionality.
Steps:
<script language="JavaScript">
_spBodyOnLoadFunctionNames.push("rewriteLinks");
function rewriteLinks() {
//create an array to store all
var anchors = document.getElementsByTagName("a");
//loop through the array
for (var x=0; x<anchors.length; x++) {
//check to see if the current anchor element contain #openinnewwindow
if (anchors[x].outerHTML.indexOf('#openinnewwindow')>0) {
//add the [target] attribute and rewrite the [href] attribute
anchors[x].target = "_blank";
anchors[x].href = anchors[x].href.replace(/#openinnewwindow/,'');
}
}
}
</script>
Counterintuitively, Site Columns -- probably FieldRefs inside of Content Types -- are stored in the [ContentTypeUsage] table. Futhermore, and also counterintuitively, the site column (field) ID is stored in the [ListId] column, and the [IsFieldId] field is zero.
SPView.ViewFields is a collection of internal field names, according to MSDN. (It is not a list of display names, as can be seen by examining the view fields of the 'UserInformationList' list).
This is surprisingly inconvenient, as SPList.Fields is indexed only by display name (or GUID, or index), and not by internal name at all.
Therefore, to map from internal names (such as are held in SPViewFields, or are encoded in CAML expressions), one cannot simply use the SPList.Fields accessor. One needs first build a dictionary mapping all internal names to something useful (e.g., GUID).
I can only guess that the SharePoint internal code uses some other (inaccessible) means for finding fields from the internal names -- which it must do frequently in rendering views and CAML.