03-31-2011, 11:02 AM
I would like to see the following functionality. Would anyone find this useful?
The ability to store hierarchical relationships between documents. Any document can have multiple parents, and multiple children, i.e. a document could be a part of a larger document, or a document could have multiple sub-documents (chapters, etc.) The details.php page would show this relationship in a treeview. An effective way to store the relationships in the database would be with a _relationships table. Functionality would be driven by two fields (parent, child) that store data ('id') from _data. Query the 'parent' field with the document id to find the sub-documents; query the 'child' field with the document id to find where the document is used. When a revision is done, only the subject document is revised, i.e. the child and parent documents are not revised.
In terms of a practical workflow, when a review is done only the subject document should be rigidly considered part of the review. The child and parent documents should also be taken into consideration, but the extent of review should be left to the diligence of the reviewer - those documents would not necessarily be within the scope of approval.
This would be useful when a "container" is desired for a group of documents, for example an ISO 9001 Quality Manual. The top level quality manual would encompass a number of sub-documents, to be revised/reviewed by many reviewers. The review of the top level document would require ensuring the sub-documents are revised/appropriate, but the actual editing of the sub-documents would be the responsibilities of others.
The "container" paradigm is also popular when all the documents related to a topic are desired to be seen as a group.
The ability to store hierarchical relationships between documents. Any document can have multiple parents, and multiple children, i.e. a document could be a part of a larger document, or a document could have multiple sub-documents (chapters, etc.) The details.php page would show this relationship in a treeview. An effective way to store the relationships in the database would be with a _relationships table. Functionality would be driven by two fields (parent, child) that store data ('id') from _data. Query the 'parent' field with the document id to find the sub-documents; query the 'child' field with the document id to find where the document is used. When a revision is done, only the subject document is revised, i.e. the child and parent documents are not revised.
In terms of a practical workflow, when a review is done only the subject document should be rigidly considered part of the review. The child and parent documents should also be taken into consideration, but the extent of review should be left to the diligence of the reviewer - those documents would not necessarily be within the scope of approval.
This would be useful when a "container" is desired for a group of documents, for example an ISO 9001 Quality Manual. The top level quality manual would encompass a number of sub-documents, to be revised/reviewed by many reviewers. The review of the top level document would require ensuring the sub-documents are revised/appropriate, but the actual editing of the sub-documents would be the responsibilities of others.
The "container" paradigm is also popular when all the documents related to a topic are desired to be seen as a group.