

You can follow the example of the standard Document Library template and use the script in the Quyerymodechange event which prevents editing any Response document (Conflicts are Responses) with the 1st level form. There are several ways to deal with this:ĭon’t let users save changes on Conflict documents (this would prevent them from breaking the Parent/Response link). This can lead to duplicate documents in a database. However, once you edit and save them, their new form-level designation as a “main document” can and will override their document-level Response status. You should be aware of the following potential problems with form-level hierarchy:Ĭonflict documents are Response documents. first-level, main or parent), Response (second level) or Response to Response (third level). There are three ways to program Parents and Responses at the form level: Forms can be set as Document (i.e. (You technically could create a solution in a custom design, using text type fields to identify Parents, but this sort of thing is very complicated to set up and has the disadvantage of not supporting the native Parent/Response navigation scheme). If the $REF item is missing or in an incorrect format (it must be a special item type-more on this later) it can’t be a native Response document. The only thing that is responsible for the Parent/Response dependency is the presence of a $REF item in response document (populated with the UNID of the Parent document) this is what links the Response to its Parent. However, views are limited to displaying a maximum of 31 levels of Responses to one main document (from R5 to R8.5.x). There is no practical limit to the number of descendant generations a document can have. You can describe documents as Parents or main documents Response documents (children) or Response to Response documents (grand children). Documents created in databases can have a relationship to facilitate easier categorization and/or grouping this is usually called the ‘ Parent/Response relationship.’
