= DrawMGT Release V12.1 = == Description == V12.1 is the same as V12.0 with the following updates: 1. Multi-classifications 1. Other DB model updates -- '''not yet completely defined''' == Next Steps == 1. Clarify requirements with Martin Smith for front-page 1. 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 1. Ability to create a work breakdown structure of tasks (parent-child tasks) * E.g. task X has sub-tasks Y1, Y2, etc. 1. Ability to display/list the hierarchical structure of documents/tasks (perhaps combined) 1. 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 1. 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? 1. Must the front-page be a ''document'' (e.g. stored as a downloadable file)? '''Suggested Fields for Front Page''' 1. Title fields 1. Keywords 1. Abstract (executive summary) * Table of contents * Issues * Recommendations * References to (Handle via doc-doc links) * Previous documentation * Third party documentation 1. Document code 1. Related documents: * Able to create separate/multiple lists or related based on the link type 1. 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 1. Multiple formats (.pdf, .doc, .rtf, etc.) of the same document 1. 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. 1. 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) 1. 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 1. Ability to have a null document code (Drawings.drawingCode) '''Possible Implementation''' 1. Add new database field: Drawings.serialNo, char(16) 1. Suggested format '''YYYYMMDDnnnn''' * YYYYMMDD = Date * nnnn = running number 1. 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 1. 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? 1. 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 1. How to handle validations on data entry?