DrawMGT Release V12.1

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

Incoming Serial Number for Documents

Copyright 2008, SoftXS GmbH, Switzerland