The Document Information Panel is great – it allows you to surface metadata to be filled in about a Word 2007 document in the client.
This is great, but I had a bit of a puzzling problem. I’ve set Libraries up to use this features many times now, and it’s pretty straight forward – I’ve added columns to the library, and then the template document for the library has included those columns. Thus, you just go into your document library, click new, and you get a blank word document with the correct document information panel thing. Sometimes I’ve modified that template, but that’s pretty straight forward through the Library Settings pages (Document Library Settings > Advanced Settings > Edit Template).
This time, though, I was using content types (i.e. setting up the library properly), rather than just adding columns directly to a list. Content Types encapsulate (amongst other things) their own set of metadata to be captured – so in other words, they define columns to be added to a list. That’s fine (and very useful).
However, when I went to my document library, clicked ‘New’ and selected my Content Type, I got a blank word document with only one field in the document information panel – title. The blankness was expected (I’d not defined my own template) but none of the other bits of metadata I’d defined for my content type were there. This was a bit of a puzzle. What was different?
Well, after much thinking, I realised something – Content Types ‘inherit’ from each other. My Content Type derived from the Document content type, which specified just one field of metadata – Title. Then it hit me – content types themselves have document templates. My new content type was inheriting from Document, and it was still using the Document content type’s template document. I specified my own template document for my content type and suddenly I had all of my fields available in the document information panel.
It is interesting that there is this difference between the document information panel fields being defined by the library when just using the default ‘Document‘ content type and no others, and the fields being defined by the content type you’ve created if you’re using other types (I.e. you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page).
Related to this, then, is the question of what happen if you add a column to a list. However, I’ll cover this in another post.
9 thoughts on “Missing Content Type fields in the Document Information Panel”
I’ve created my own content type. I’ve specified my own template document in the advanced settings of the content type with the url of a template from a document library within my Document center site (I used the option: Enter the URL of an existing document template). If I create a new document library with the content type it will open the appropriate template but the DIP reflects that of the Document content type, with the one metadata – title field. If I use the other option in the advanced settings of the content type (Upload a new document template:), I get the appropriate metdata in my DIP. Do you know why this is? I would think referencing a template from a url would only provide the template for that content type and the document library would still use the metadata for that particular content type.
Nope, I’ve gotta admit I’ve not tried using the URL of an existing template. It sounds like that URL field value might be the thing that was inherited by the child content type, and that the ‘Upload a new document template’ option overrides that. I might take a look to see. I don’t suppose you happen to know what the URL to the existing template was and what the URL to the newly uploaded template became? That might tell us something.
I’ll maybe take a look, and report back if I find anything…
That is an interesting question. If you enter the URL of an existing document template, it becomes something like http://intranet/Docs/Templates/NotesTemplate.dotx. However, when you use the Upload a new document template, the URL of the newly uploaded template is just the file name (i.e. – NotesTemplate.dotx). I’m not sure whether or not this is a bug or normal functionality.
[…] This is sort of relevant to an earlier post on the Document Information Panel, and showing fields in it. […]
I think internally it must be a full URL, it’s just not showing all of it. I tried that and got the same thing with the URL or filename being displayed, although I also wasn’t actually able to replicate the original problem of making fields not appear!
Still, I think it makes sense – for some reason my child content type must still have had the URL to the parent content type’s template file.
Bit miffed that I couldn’t replicate the problem though. Might try again tomorrow…
One interesting note. I added a column to my Document Center Document library where my templates reside. I then went back to my Document Library that references that template within my Content TYpe. I created a new document of that content type and the DIP showed the new column I had added to the document library of my templates. It seems to be using the metadata of the templates library? Is this some kind of inheritance issue?
[…] then just saved the template without making any changes – I’ve found that you need to do this to get the Document information panel to work […]
I’m having the exact same issue as you’ve described Adrian, with funny behaviour when my templates are associated by URL…
The templates are word documents, and they open up properly, but as soon as the user tries to save back to the document library it seems that SharePoint forgets which content type it is saving… instead it saves the document as the list’s ‘default’ content type (which in this case is ‘word document’).
This issue goes away when my templates are uploaded directly to the content type, but the ability to maintain the templates in a document library and attach the URL instead is of high importance in this case.
Has anybody made progress on this issue? Thanks in advance.
I don’t know if you ever found a solution. You can check this url: http://weblogs.asp.net/mnissen/archive/2008/10/18/sensible-document-template-file-management-with-sharepoint.aspx. It’s what I used in our case.