Differences between revisions 6 and 7
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
 1. Enumerize gem is utilized for Transmittal.status and Transmittal``Recipient.recipient_type

V2 Transmittals

V2Master

  • 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?
  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

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

  10. Keep email address at transmission?
  11. Should TransmittalRevision contain also asset_file_id or separate model (TransmittalRevisionFile)

  12. Float forms are OK? As at Document and Revision New? Or should we change to table form?
  13. Enumerize gem is utilized for Transmittal.status and TransmittalRecipient.recipient_type

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

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

Copyright 2008-2014, SoftXS GmbH, Switzerland