Multiple File Versions

Introduction

Multiple file versions allow DrawMGT users to upload a new file 'on top of' a previously uploaded file. The previously uploaded files are still kept in the system and can be downloaded.

• In lists only links for the most recently uploaded version of each file type are visible
• In the document detail screen the complete list of versions for each file type could be displayed for the selected revision

It will be possible to have an optional note (or short description) associated with each uploaded file.

Each uploaded file has the following attributes:

• The upload file
• The file type (source, publish, etc.).
  • The allowed file types are defined in the project configuration (probably in a reference table in the database)
• The date and time the file was uploaded
• The name of user that uploaded the file.

  • Need to decide if this should be displayed on the revision detail screen or a file history screen

• A text description note that entered by the user when the file is uploaded
  • Can this be edited later? Probably, perhaps via a REST dialog

Multiple file versions could be used as sub-revisions to record the updates and changes to a file as it is prepared. This could replace the use of tasks as containers for the notes and attachments during document and drawing preparation and markup.

The display of certain file types could be based on user roles. E.g. users who do not have the file upload or drawing update roles man not be able to see certain file types (handled by flags in the file type reference table) or not be able to see the non-latest file versions.

Open Points

Note: See also the open points in the Code Areas to Change section.

• File naming: E.g. Multiple publish files for a revision will all have the same filename and when they are downloaded, then there will be certainly be confusion.

  • Possible solution: latest file has the normal name (code-rev.pdf) and the previous files have a date-time stamp added before the file extension (code-rev-YYYYMMDD-hhmmss.pdf)

• Will it be necessary to associate specific version of different file types? E.g. A source file is uploaded and then a different user prints it and does some markup, scans it and uploads the scan as new version of the markup file. Later, how do you associate the source file with the markup file(s) for it? This could be difficult if multiple markup files are uploaded (perhaps from different users) for a single source or publish file.

• What should the user interface for this look like?
  • Updating notes for previous file versions
  • Displaying lists of previous files in detail screens

• File locking: when a workflow step is completed, should certain file types be locked

  • Disable file delete
  • Disable further uploads?

Suggested design principle: We will probably not be able to figure out exactly what users want, so we should just implement the minimum functionality required for Cardenillo, but expect to make additions and changes later as more projects use this feature.

Goals

• Keep all uploaded revision files, even if a file was deleted on the GUI
• Possibility for admins to restore deleted, overwritten files
• Using file types (publish, source, etc,) generally, to allow different number of file types, not hard-coded

Data Model

1. New table UploadFileTypeRef contains the upload file types, with a flag that the type can be uploaded

2. New table UploadFiles contains the

   • Reference to the object (Revisions, CommentNotes)

   • File type (PDF, DOC, etc.)
   • File size
   • Filename
   • File version (sequence number)
   • Deleted flag
   • Thumbnail file name

     Note that the table name UploadedFiles is already used in the vendor portal.

3. Table Revisions: all upload file informations will be removed

File Storage

• File could be stored in the same way as today, but the fie version (number?) appended (perhaps before the fileTypeId)

Code Areas to Change

1. Drawing Code Class
   • All functions returning file names, links, path, checking file names

2. Settings-DrawingCode.php

   • OPEN POINT: How to change file name definition?
3. Revision File Delete

   • Only the delete flag will be set in the UploadFiles record, neither the UploadFiles record nor the file will be deleted

4. Revision File Upload

   • New UploadFiles record created with the next file version number

   • OPEN POINT: Should we allow to upload a file also if there is already one uploaded?
5. Revision Delete
   • See Revision File Delete above
6. Validation
   • Work flow step can be completed only if specific type of upload file is uploaded
     • Type of upload file is from $_CFG
     • Type is defined in table WFStepTypeRef if the new work flow schema is used for revisions
7. Comment Note Attachment Delete
   • New function
8. Comment Note Attachment Upload
9. Thumbnail generation
   • Filenames created differently

10. Revisions, DrawingsRevisionsJoin dereference method

11. Drawings, Basket listsű
12. Submittal, Transmittal File Selection
    • Javascript to select file types

Migration