Custom Document Information Panels in SharePoint Server 2010 (ECM)

Last modified: August 10, 2010

Applies to: SharePoint Server 2010

In this article
Developing Custom Document Information Panels
Publishing Custom Document Information Panels
Pushing Down Changes to the Document Information Panel

Microsoft SharePoint Server 2010 gives you the option of creating custom document information panels using Microsoft InfoPath 2010. These custom forms are then displayed in place of the autogenerated forms.

You can create one custom document panel per content type, although that panel, like any other InfoPath 2010 form, can have multiple views. Microsoft SharePoint Foundation 2010 also provides you with the autogenerated form as a starting point.

Because content types can be file-type independent, the same custom information panel is displayed within each of the Microsoft Office 2010 client applications. For example, if you assign the same content type to a Microsoft Word 2010 document and a Microsoft PowerPoint 2010, you still specify only one custom document information panel, which would be displayed in each application.

NoteNote

Custom document information panels enable users to enter and edit content type properties for a document from within the client application. As a result, they differ from custom content type Edit forms, which are used to enable the user to edit content type properties for a document from within the SharePoint Foundation 2010 user interface.

You can create custom document information panels for both site and list content types.

Because document information panels are for documents, you can create custom panels only for content types that inherit from the Document content type. For example, you cannot create a custom document information panel based on a list schema.

Developing Custom Document Information Panels

You can create custom document information panels in two ways:

  • Starting from the SharePoint Server 2010 user interface, you can choose the content type for which you want to create a custom document information panel. SharePoint Server 2010 launches InfoPath 2010, and supplies the content type schema as the primary data source, as well as the automatically generated form as a starting point. When you are finished with the form, you can publish it directly to the content type or to some other location.

    NoteNote

    To be able to publish the form to the content type, you must first enable multiple content types for the document library.

  • Starting from the InfoPath 2010 application, you can browse to the desired site or list and select the content type for which you want to create a custom document information panel. InfoPath 2010 sets the selected content type as your primary data source, as well as the automatically generated form as a starting point. When finished with the form, you can publish it to the content type or to some other location.

In either case, the InfoPath 2010 form stores the content type ID of the content type for which it was created. This information is stored within the XSN file as an XSF entry at /xsf:xDocumentClass/xsf:extensions/xsf2:solutionPropertiesExtension/xsf2:contentTyp.

For more information, see How to: Create or Edit a Custom Document Information Panel from within Office SharePoint Server 2007 and How to: Create a Custom Document Information Panel from InfoPath in SharePoint Server 2010 (ECM).

Publishing Custom Document Information Panels

As with any InfoPath 2010 form, the location to which you publish your custom document information panel, and the security level with which you publish it, have important ramifications. You should consider these before you publish your form.

Publishing Locations

You can choose to publish the custom document information panel either directly to the content type resource folder or to a separate location. Each approach has advantages.

Publishing directly to the content type resource folder guarantees that the form is published to the Microsoft SharePoint Server 2010 computer on which the content type, and the documents it has been assigned to, also reside. The form is published to the same folder as the other resource files for this content type.

Publishing to a separate location enables you to store all your forms in a central location, for example, in a forms library. This scenario enables you to restrict who has access to working on those forms. In addition, it enables developers who may not have access to the SharePoint Server 2010 site to work on the forms for that site.

Security Considerations

Custom document information panels can have only Restricted or Full Trust security levels and domain. If you specify Full Trust, you need to digitally sign the InfoPath 2010 template to deploy it to the content type resource file or other shared location. Otherwise, you must deploy the template as an installed registered template.

Because of security considerations, we recommend you publish the XSN for your custom form to the same domain as the documents for which you want to use it. Otherwise, the custom form opens in Restricted mode, and the data connections will not work. Saving the form locally will also cause any form that is not fully trusted to open in Restricted mode.

If you do save your custom form to a different domain, you have two options for making sure the data connections function properly:

  • Add the domain on which you saved the form to your list of fully trusted sites.

    Caution noteCaution

    Perform this action with caution; adding an entire domain to your trusted sites list can open your computer to cross-site scripting attacks. Be sure you trust the domain you are adding and all the users who have access to it.

  • Deploy the form as a Windows Installer package to install either a fully trusted form or a fully trusted and signed form.

For more information on the InfoPath 2010 forms security model, see the InfoPath developer documentation.

Pushing Down Changes to the Document Information Panel

The location of the custom document information panel, and its settings, is stored in content types as an XML document.

Push-down operations are scoped to the XML document level. If you make any changes to the XML document that pertains to the custom document information panel, and then push down those changes, the entire XML document, not just the settings you changed, is overwritten in any child content types,.

For example, if you create a custom document information panel for a site content type, and perform a push-down operation, all child content types based on that site content type are updated to use that custom document information panel.

To help avoid such conflicts, we recommend that you be aware of any changes made to child content types before pushing down changes involving custom document information panels. In addition, you can limit whether push-down operations affect the child content type by defining it as read-only or sealed. Defining a content type as read-only prevents users from editing the content type using the Microsoft SharePoint Foundation 2010 user interface. However, you can still set the content type to allow read/write operations using the object model, and update the content type in that way. Similarly, you cannot change sealed content types through the user interface or object model. To change a sealed content type, you must change the content type definition itself—the XML file used to provision the content type. Sealed content types are not updated through any push-down operations.

For more information, see Updating Child Content Types in the Windows SharePoint Services 3.0 General Reference.

Pushing down changes might prove problematic if you have made changes to a child content type. For example, if you added or removed a column from the child content type, then the schema of the custom document information panel, while matching the schema of the parent content type, would not match the schema of the child content type.

A better solution is to select to update the custom property panel by opening the form in Microsoft InfoPath 2010, and then clicking Refresh Fields on the Data tab. Instead of leaving the data source as the parent content type, point to the child content type instead.

NoteNote

This does not update the view; you must add or remove controls to reflect the new data source schema. You must also update any business logic that is dependent upon removed controls. For more information, see How to: Update a Document Information Panel for Content Type Changes in SharePoint Server 2010 (ECM).

You cannot prevent users from creating content types based on a specific content type.