• DrawMGTRelease121

DrawMGT Release V12.1

Multipile Classifications

1. See MultiClassification

Doc-to-Doc and Task-to-Task Links

Requirements

1. Link related documents:
   • Different language versions of same documents (might be solved by multi-file per revision)
   • Document X replaces document Y

   • Document X is a reply to document Y (correspondence chains)

   • Ability to make certificate hierarchies. E.g. document X complete implies sub-documents Y1, Y2, etc. complete.
   • Ability to create composite documents out of sub-documents
2. Ability to create a work breakdown structure of tasks (parent-child tasks)
   • E.g. task X has sub-tasks Y1, Y2, etc.
3. Ability to display/list the hierarchical structure of documents/tasks (perhaps combined)

4. Need to have set of link-types, which the project can define.

   • May need to be able to change a link from a revision to a document, or document to a revision

Possible Implementations

1. Add new many-to-many link tables (doc-doc table, task-task table) -- NO

   • New table (example):
     • fromDrawingId
     • toDrawingId
     • linkTypeId
   • Disadvantage: Have to search in many tables

2. Extend the existing CommentRevisions table with objectId fields: -- YES

   • Fixes problem of linking a document (without revision) to a task

   • CommentRevisions (name change to ObjectLinks?) gets the following fields (all id fields form the primary key):

     • fromObjectTypeId
     • fromObjectId
     • toObjectTypeId
     • toObjectId
     • linkTypeId
     • note (optional text that the user can add to describe the link)
   • Disadvantage: Have to fix/update some existing code
   • Advantage: ALlows links between pretty much anything in the system (revisions, submittals, etc.)

   • Need to have link-type included with the link (e.g. new table LinkTypeRef)

Link types

1. Implement with a standard reference table. E.g. id, code, name, description, define, order(?)

Fields for Front-Page

Requirements

1. MS/MET wants DrawMGT to generate a MS Word (or RTF?) document that a user can fill in
   • We would rather store the front-page as metadata in the database, and not generate this file

2. It is unclear if the front-page is per document, or if it should be available for each revision of the document

   • Do we need to implement any kind of version control on the front-page?

3. Must the front-page be a document (e.g. stored as a downloadable file)?

Next Step

1. Need to clarify the requirements with Martin Smith

Suggested Fields for Front Page

1. Title fields
2. Keywords
3. Abstract (executive summary)
4. Document code
5. Related documents:
   • Able to create separate/multiple lists or related based on the link type
6. Revision history:
   • Revision code
   • Final workflow date
   • Initials (or who?)
   • Reason for issue
   • Description

Multiple Files per Revision

Requirements

1. Multiple language versions of the same document
2. Multiple formats (.doc, .rtf, etc.) of the same document
3. Multi-part documents and appendices (probably better to use document/revision links)

Possible Implementation

1. RevisionFiles table, fields:

   • revisionId
   • fileTypeId (encodes extension)
   • languageId (inclues N/A?)
   • comment (human readable note)
   • fileName
   • file size / checksum ?
   • source/publish file flag
   • object subtype (thumbnail, etc.)?

Issues

1. Submittals? E.g.
   • which file goes into the submittal zip file? All publish files?
   • Require 1 or X publish files to be present?
2. How to handle automatic file naming (e.g. drawings?)
   • Must files have different names? How to enforce this?
   • Should disable 'code' based file naming
3. Can you block multiple files per revision?
   • Based on document type? Could have a new flag field in Drawings or Revisions?

Incoming Serial Number for Documents