Custom Document Information Panels

Microsoft Office SharePoint Server 2007 gives you the option of creating custom document information panels using Microsoft Office InfoPath 2007. These custom forms are then displayed in place of the autogenerated forms for Microsoft Office Professional 2007 and Microsoft Office Enterprise 2007 users.

Note

Custom document information panels are displayed only in Office Professional 2007 and Office Enterprise 2007 applications.

You can create one custom document panel per content type, although that panel, like any other Microsoft Office InfoPath 2007 form, can have multiple views. Windows SharePoint Services 3.0 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 2007 Microsoft Office system client applications. For example, if you assign the same content type to a Microsoft Office Word document and a Microsoft Office PowerPoint presentation, you still specify only one custom document information panel, which would be displayed in each application.

Note

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 Windows SharePoint Services 3.0 user interface. For more information about specifying custom content type Edit forms, see Content Type Forms Schema Overview in the Microsoft Windows SharePoint Services 3.0 SDK.

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 Office SharePoint Server 2007 user interface, you can choose the content type for which you want to create a custom document information panel. Office SharePoint Server 2007 launches Microsoft Office InfoPath 2007, 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.

    Note

    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 Microsoft Office InfoPath 2007 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. Microsoft Office InfoPath 2007 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 Microsoft Office InfoPath 2007 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.

Publishing Custom Document Information Panels

As with any Microsoft Office InfoPath 2007 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 SharePoint Server 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 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 Microsoft Office InfoPath 2007 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.

    Warning

    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 Microsoft Windows Installer to install either a fully trusted form or a fully trusted and signed form.

For more information on the Microsoft Office InfoPath 2007 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 Windows SharePoint Services 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 Content Types in the Microsoft Windows SharePoint Services V3SDK.

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 Office InfoPath and running the Convert Main Data Source Wizard. Instead of leaving the data source as the parent content type, point to the child content type instead.

Note

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.

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

See Also

Tasks

How to: Create or Edit a Custom Document Information Panel from within Office SharePoint Server 2007
How to: Create a Custom Document Information Panel from InfoPath
How to: Update a Document Information Panel for Content Type Changes

Concepts

Document Information Panel Overview
Custom Document Information Panels
Content Type Document Information Panel Schema