DrawMGT Release V12.1

Description

V12.1 is the same as V12.0 with the following updates:

1. Multi-classifications

2. Other DB model updates -- not yet completely defined

Next Steps

1. Clarify requirements with Martin Smith for front-page
2. Catalog database model updates

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)?

Suggested Fields for Front Page

1. Title fields
2. Keywords
3. Abstract (executive summary)
   • Table of contents
   • Issues
   • Recommendations
   • References to (Handle via doc-doc links)
     • Previous documentation
     • Third party documentation
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 (.pdf, .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 and mime type)
   • languageId (inclues N/A?)
   • comment (human readable note)
   • fileName
   • file size
   • file checksum?
   • source/publish file flag
   • object subtype (thumbnail, etc.)?

2. The creation of a front-page report of display page could be implemented using site specific layout templates

   • Issues:
     • Have to display a complete page consisting of various components, including the document layout, linked documents,
       • revision workflow. This may be difficult to implement in a single template. It if further complicated by the customer wanting to specify their own ordering of the components (or even wanting to mix information from different components in a single part of the front-page
     • Might be able to define a master data structure for a document and its revisions and linked documents, which
       • can be passed to a generic template for display.

Issues

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

Incoming Serial Number for Documents

Requirements

1. Ability to have a unique system-generate id value (that has some meaning to the user)

   • The id is assigned once (to a document) can never be changed

2. Ability to have a null document code (Drawings.drawingCode)

Possible Implementation

1. Add new database field: Drawings.serialNo, char(16)

2. Suggested format YYYYMMDDnnnn

   • YYYYMMDD = Date
   • nnnn = running number

3. Could also implement a printf-like format string (like how the unix date command works)

   • Default format (describe above) would be a general setting, which could be overridden by a site specific setting

4. Display undefined (a string taken from Settings.php) as the document code, when the code is null.

   • Or alternatively, copy the id in the document code as well (which means you have to set an appropriate drawingCode type).
     • How to reset the drawing code type when the user assigns the proper code?

5. Could have a document type undefined, which the user has to change when he wants to enter a code. E.g. if you have

   • documentType = undefined, then the id field is copied to the drawingCode.

Issues

1. Metadata upload current requires a drawing code as a key
2. How to handle validations on data entry?