V2 Transmittals

V2Master

Issues

First Release

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

      • Answer: Yes NOT IMPLEMENTED YET

    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 NOT IMPLEMENTED YET

Design Issues to Discuss

  1. ZIP files stored or created during download?

    • Answer: ZIP files should be created during download DONE 2013-10-31

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

    2. The following directory structure implemented: <<revision full code>>/<<file category>>/<<file type>>/<<file name>>[-[1-9]] DONE 2013-10-31

  3. Revision 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 DONE 2013-10-31

  5. How should transmittal codes be generated?

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

  6. What roles if required for creating a transmittal?

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

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

    • Answer: to be determined suggest yes NOT IMPLEMENTED YET

  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 NOT IMPLEMENTED YET What's about external users?

  9. TransmittalRecipient should be user (primary email), email_address or user & email_address

    • Answer: user & email_address DONE 2013-10-31

  10. Keep email address at transmission?

    • Answer: yes DONE 2013-10-31

  11. Should TransmittalRevision contain also asset_file_id or separate model (TransmittalRevisionFile)

    • Answer: 2 level of associations fit better into rails way: transmittal_revisions/transmittal_files DONE 2013-10-31

  12. Float forms are OK? As at Document and Revision New? Or should we change to table form?

    • Answer: closable nested forms are used DONE 2013-10-31

  13. Enumerize gem is utilized for Transmittal.status and TransmittalRecipient.recipient_type

    • Answer: yes DONE 2013-10-31

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 DONE 2013-10-31

  2. Sending a transmittal (in the first release):

    1. Sends an HTML formatted email DONE 2013-10-31

    2. To all recipients DONE 2013-10-31

    3. The email contains a link, with a personalized key, for downloading a ZIP file with all the files DONE 2013-10-31

    4. A audit trail record is made when it is sent NOT IMPLEMENTED YET - the audit trail record doesn't say anything currently, not even the key is stored

  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 DONE 2013-10-31

  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 IMPLEMENTED BUT not even metadata change is possible

    2. File versioning is required DONE 2013-10-31

  5. If a transmittal has not been sent, it can be: DONE 2013-10-31

    1. Edited
    2. Deleted
    3. Recipients can be added and removed
    4. Revisions can be added and removed

  6. You can clone a transmittal NOT IMPLEMENTED YET

    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 NOT IMPLEMENTED YET

    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 NOT IMPLEMENTED YET

    2. The revisions NOT IMPLEMENTED YET

  9. When a ZIP file is downloaded using an email link, an audit trail record is made containing:

    1. Date and time DONE 2013-10-31

    2. Recipient identification NOT IMPLEMENTED YET

    3. IP address DONE 2013-10-31

Transmittal Email

  1. Transmittal code (automatically generated by the system?) NOT IMPLEMENTED YET

  2. Date (set automatically when sent)

  3. Sender (selected from the user list) DONE 2013-10-31

    1. User must have a role matching the folder (what role?) NOT IMPLEMENTED YET

  4. Email subject line, built from:

    1. Project name/code NOT IMPLEMENTED YET

    2. Transmittal code DONE 2013-10-31

    3. Transmittal title DONE 2013-10-31

  5. Transmittal title
  6. Classification codes

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

    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 DONE 2013-10-31

    2. Revision code DONE 2013-10-31

    3. Title DONE 2013-10-31

    4. Revision Date NOT IMPLEMENTED YET

    5. File information for each file: DONE 2013-10-31

      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 DONE 2013-10-31

  2. Use file versioning instead of creating ZIP files in order to ensure that the exact transmittal is maintained DONE 2013-10-31

Permissions

  1. Transmittals are stored in a folder DONE 2013-10-31

  2. The folder must be writable by the transmittal sender and the current user NOT IMPLEMENTED YET for the sender

  3. The files being sent must be readable by the sender and the current user NOT IMPLEMENTED YET for the sender

  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 DONE 2013-10-31

    2. You see the complete file list, but you may not be able to see the detail screens all of them DONE 2013-10-31

  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 NOT IMPLEMENTED YET

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

    • Answer: no, it should be canceled and re-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

Selecting Recipients

  1. All recipients must be registered in the system, with the minimum metadata:
    1. Must have an email, name, company, description (e.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) NOT IMPLEMENTED YET

  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 DONE 2013-10-31

    2. Baskets NOT IMPLEMENTED YET

Selecting Revisions

  1. Document revisions are sent in transmittals (not files) DONE 2013-10-31

  2. When a revision is part of a transmittal the corresponding document detail page will contain a link it DONE 2013-10-31

    1. The ability to see the link is subject to user's ability to read the transmittal's folder NOT IMPLEMENTED YET

  3. Use the basket to put documents in a transmittal DONE 2013-10-31

    1. Probably need a refresh basket select list, to allow users to create a basket in a different window NOT IMPLEMENTED YET but needed? Transmittal can be saved without attached revisions.

Selecting Files

  1. Only files attached to revisions can be sent DONE 2013-10-31

  2. Any file and all revision file types can be sent, including both revision and working files DONE 2013-10-31

  3. It is possible to select the file type(s) on an individual revision and file basis DONE 2013-10-31

  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 DONE 2013-10-31

    2. File type DONE 2013-10-31

    3. File format NOT IMPLEMENTED YET but really needed?

  5. Revisions can be added to a transmittal via baskets (lists) DONE 2013-10-31

Listing Transmittals

  1. It is possible to list transmittals DONE 2013-10-31

  2. Sort/search by: DONE 2013-10-31

    1. Title
    2. Description
    3. Date
    4. Sender
    5. Recipient
    6. Folder
    7. Classification fields

Future Release

V2Transmittals (last edited 2013-11-05 09:30:18 by 172)

Copyright 2008-2014, SoftXS GmbH, Switzerland