This topic describes the node properties managed by the Document Manager application, Content Model, or underlying JCR repository. Changes to these fields using the builder are ignored.
Unique identifier for each node in the JCR tree.path
Hierarchical path to the node in the tree. lastModified
Date the node was last modified.created
Date the node was created.creator
Name of person who created the nodelastModifier
Name of person who last modified the nodedataLength
Size of the data stored in the data field of the node.dataLastModified
Last modified date of the data stored in the data field of the node.Revision
Revision level of the document.label
The Content Model uses the label property as the file portion of the hierarchical file path in the Content Model. For example, if the label is status_report.doc, the JCR path can be /documentRoot/icm:libraries/folder1/status_report.doc. Like a file system, this value must be unique.dataMimeType
The label property must be set to a unique value when creating a new document or folder in the Content Model. Therefore, when using the createDocument data service of this builder, you must set a unique value for label property. If this property is not set or if a path already exists at this location, you receive a Content Model error and the new document or folder is not created. Implement a field validation in your web application to ensure this field is set for new documents.
If the property is set, the Content Model does not allow you to change the label property, as it becomes part of the path property. Therefore, if you use the updateDocument Data Service of this builder to update an existing document, the builder ignores changes to this field. Hide this field (for instance, using a Data Column Modifier builder) in the update functionality of your web application.
Set the dataMimeType field to the appropriate MIME type for the uploaded document.effectiveDate
This property is used by the Document Manager application. Document Manager displays CollaborativeDocuments where the effectiveDate is now or in the past. If the effectiveDate is set to a future date, the CollaborativeDocument does not show in Document Manager until that date. Also, if the effectiveDate is not set, the CollaborativeDocument does not show in Document Manager. Therefore, if use the builder to operate on CollaborativeDocuments, take special care to set this field appropriately.revision
Documents of type CollaborativeDocument are used by Document Manger and other IBM® WebSphere® Portal applications. CollaborativeDocument contains all the common properties of document, but with additional application-specific properties used and managed by the Document Manager portlet and Manage Document Libraries portlet. One notable example is the CollaborativeDocument property revision which is managed by Document Manager. The revision field is used by the Document Manager portlet to determine which rendition of the document to show.
To ensure that CollaborativeDocuments modified with this builder continue to work correctly in the Document Manager portlet, the builder updates CollaborativeDocument properties using the Content Model API DMUtility methods. In addition to updating fields on the document, these methods automatically adjust the revision field of the CollaborativeDocument. Direct changes to the revision field using the builder are ignored.
For all other Documents and descendants, the builder simply updates properties at the SDO level.
Parent topic: Portal Document Manager Access builder