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

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?

DrawMGTRelease121 (last edited 2009-10-20 16:22:34 by 183-56-147)

Copyright 2008, SoftXS GmbH, Switzerland