V2 File Handling

V2Master

• Contents

  1. V2 File Handling
  2. Issues
     1. First Release
     2. Design Issues to Discuss
     3. Items to Prototype
  3. Requirements
  4. Transmittal Email
  5. Transmittal ZIP Files
  6. Permissions
  7. Transmittal Metadata
     1. Metadata Fields
  8. Selecting Recipients
  9. Selecting Revisions
  10. Selecting Files
  11. Listing Transmittals
  12. Future Release

• 2013.08.31 AH & JK

• 2013.09.03 AH & TN reveiw

Issues

First Release

1. What is included in the first release?
   1. Clone transmittal?

      • Answer: Yes

   2. Automatically link cloned transmittal?

      • Answer: No. If time allows define the link table and create the link record. But do not implement the fron-ent for displaying and editing them

Design Issues to Discuss

1. ZIP files stored or created during download?

   • Answer: ZIP files should be created during download

2. What is the internal structure of the ZIP files
   1. It is possible to have revision files with the same names

   2. Answer: to be determined

3. Revision file versioning?

   • Answer: Yes. See File Versioning

4. Keep names and email addresses for non-system users in the Users table or somewhere else?

   1. Try to avoid re-factoring all the session and access/permissioning code
   2. Consider security issues
   3. Would like to be able to create a contact list of all project members, including the external contacts

   4. Answer: Keep external recipients in the Users and Email Addresses tables

5. How should transmittal codes be generated?

   • Answer: Build from an application setting Setting.SXS.Application.Transmittal.Code.Prefix and append the transmittal id

6. What roles if required for creating a transmittal?

   • Answer: to be determined, based on recommendations from JK in his Useability Review

7. Should we restrict the viewing of unsent transmittals? E.g. only update and above sees pending transmittals

   • Answer: to be determined suggest yes

8. Should HTML emails have live links in the document/file list for downloading the files?

   • Answer: to be determined suggest yes, if it is easy

Items to Prototype

1. Recipient selection
2. Revision and revision file selection

Requirements

1. You can send revisions to recipients that do not have a system login
2. Sending a transmittal (in the first release):
   1. Sends an HTML formatted email
   2. To all recipients
   3. The email contains a link, with a personalized key, for downloading a ZIP file with all the files
   4. A audit trail record is made when it is sent
3. Once a transmittal is sent it cannot be changed

   1. Means that you can always see exactly what was sent, including the exact copies of all files

4. Once a revision file is transmitted, the sent file(s) are are locked
   1. You cannot change the file, but can change it's metadata
   2. File versioning is required
5. If a transmittal has not been sent, it can be:
   1. Edited
   2. Deleted
   3. Recipients can be added and removed
   4. Revisions can be added and removed
6. You can clone a transmittal

   1. When cloned, the transmittal code is updated with the transmittal code prefix and has max(id)+1 and (copy) appended to it, which can be edited

   2. If you want to change a transmittal that has been sent, you have to clone it
7. You can re-send a transmittal, to the original recipients, provided nothing is changed
   1. A audit trail record is made indicating that it was re-sent
8. The complete history of transmittal, including canceled transmittals, is retained, including:
   1. The cover letter
   2. The revisions
9. When a ZIP file is downloaded using an email link, an audit trail record is made containing:
   1. Date and time
   2. Recipient identification
   3. IP address

Transmittal Email

1. Transmittal code (automatically generated by the system?)
2. Date (set automatically when sent)
3. Sender (selected from the user list)
   1. User must have a role matching the folder (what role?)
4. Email subject line, built from:
   1. Project name/code
   2. Transmittal code
   3. Transmittal title
5. Transmittal title
6. Classification codes

   1. Only classification fields configured in the top block appear in the email

   2. Possible classification fields (which is configurable by the user)
      1. Sub-Title
      2. Description
7. Message text
8. Table of revisions being sent
   1. Document code
   2. Revision code
   3. Title
   4. Revision Date
   5. File information for each file:
      1. File category
      2. File type
      3. File name

Transmittal ZIP Files

1. Create ZIP file when transmittal is sent or when the user downloads?
   1. From the user's point of view the system creates a ZIP file when a transmittal is sent
   2. From the system point is view it is probably more efficient to generate the ZIP file during a download
2. Use file versioning instead of creating ZIP files in order to ensure that the exact transmittal is maintained

Permissions

1. Transmittals are stored in a folder
2. The folder must be writable by the transmittal sender and the current user
3. The files being sent must be readable by the sender and the current user
4. If you have permission to read a transmittal:
   1. You can download the ZIP file, which may include files that you otherwise not allowed to see
   2. You see the complete file list, but you may not be able to see the detail screens all of them

5. A permissions warning should be displayed if the user selects a revision for a transmittal, which is not in or under the transmittal's folder

   • Issue: it is possible that transmittals will be moved to a different folder after they are sent?

Transmittal Metadata

1. Code (required. must be unique)
2. Name (required)
3. Message (optional)

4. Status (set automatically. pending, in process, sent, canceled)

5. Date sent (set automatically)
6. Folder (required)
7. Classification fields (configurable. optional/required as defined by the classification configuration)

Metadata Fields

• Field Name	Type	Req.	Field Description	Notes
  id	int	YES	Record id
  folder_id	int	YES	Folder transmittal is assigned to
  transmitted_at	datetime	NO	Date/time of last time transmitted	Must be unique
  code	string	YES	Code
  title	string	YES	Title
  message	text	NO	Message text
  content(?)	text	YES	Complete formatted transmittal mess	In HTML. Generated from the other fields
  status(_id?)	?	YES	Status (pending, in process, sent, canceled)
  other fields?..
  created_at	datetime	YES	Rail record creation date/time	Set automatically
  updated_at	datetime	YES	Rails record last update date/time	Set automatically

• To be completed during the implementation

• Issues:

  • Workflows? Should there be a plan date?
  • Cancel date, reason for cancel?

Selecting Recipients

1. All recipients must be registered in the system, with the minimum metadata:
   1. Must have an email, name, company, description (.g. project position name)
   2. Description is optional and is not included in the transmittal
   3. The email address does not need to be validated
2. Would be nice to be able to register new recipients while creating a transmittal (perhaps in another window)
3. List of possible recipients includes the
   1. System users (who have logins)
   2. External (non-system) participants
   3. All project participants
4. Recipients can be selected from:
   1. The user/recipients list
   2. Baskets

Selecting Revisions

1. Document revisions are sent in transmittals (not files)
2. When a revision is part of a transmittal the corresponding document detail page will contain a link it
   1. The ability to see the link is subject to user's ability to read the transmittal's folder
3. Use the basket to put documents in a transmittal

   1. Probably need a refresh basket select list, to allow users to create a basket in a different window

Selecting Files

1. Only files attached to revisions can be sent
2. Any file and all revision file types can be sent, including both revision and working files
3. It is possible to select the file type(s) on an individual revision and file basis
4. It may be possible to select or de-select all files for the selected revisions based on:
   1. File Category, e.g. all revision or working files
   2. File type
   3. File format
5. Revisions can be added to a transmittal via baskets (lists)

Listing Transmittals

1. It is possible to list transmittals
2. Sort/search by:
   1. Title
   2. Description
   3. Date
   4. Sender
   5. Recipient
   6. Folder
   7. Classification fields

Future Release

1. Implement get the available id button (as a REST transaction) for setting the transmittal code

2. Managing download links
   1. Timeouts. Link no longer works when time limit reached
   2. Cancel download link for selected recipients
3. Promote an external user to be a system user
   1. Ideally by sending an invitation. Most of the metadata should be already setup
4. Transmittal templates
   1. Transmittal type selects a templates for:
      1. Email subject line
      2. Email message
   2. Variable substitution in templates
5. Cover letters in PDF format
   1. Automatically registered in the system as documents/revisions
   2. When a transmittal is canceled then it is stored as a new revision
6. When workflows are implemented

   1. Check box on transmittal that requires that all workflows of document must be completed

7. A transmittal clone is automatically linked to the original transmittal
   1. References (links) between transmittals can be added or deleted at any time
8. Ordering of
   1. revision files
   2. recipients
9. Cancel transmittal transaction,
   1. Transmittal status set to canceled
   2. Inform the original recipients that the transmittal is canceled
   3. A audit trail record is made indicating that it was canceled
   4. Subject line has 'CANCEL' at the start
   5. All keys for downloading the ZIP are blocked. If they are used then the system reports that the transmittal is canceled
10. Improved reporting:
    1. Transmittals and list of file sent to:
       1. An email address
       2. A domain name
    2. List of transmittals that a particular file was sent in
11. Transmitting tasks
    1. A PDF representation of the task, in it's current, is created and registered as a document/revision when the transmittal is sent