Deletions are marked like this. | Additions are marked like this. |
Line 42: | Line 42: |
1. Transmittal``Recipient should be user (primary email), email_addresse or user & email_address | 1. Transmittal``Recipient should be user (primary email), email_address or user & email_address |
V2 Transmittals
2013.08.31 AH & JK
2013.09.03 AH & TN reveiw
Issues
First Release
- What is included in the first release?
- Clone transmittal?
Answer: Yes
- 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
- Clone transmittal?
Design Issues to Discuss
- ZIP files stored or created during download?
Answer: ZIP files should be created during download
- What is the internal structure of the ZIP files
- It is possible to have revision files with the same names
Answer: to be determined
- Revision file versioning?
Answer: Yes. See File Versioning
Keep names and email addresses for non-system users in the Users table or somewhere else?
- Try to avoid re-factoring all the session and access/permissioning code
- Consider security issues
- Would like to be able to create a contact list of all project members, including the external contacts
Answer: Keep external recipients in the Users and Email Addresses tables
- How should transmittal codes be generated?
Answer: Build from an application setting Setting.SXS.Application.Transmittal.Code.Prefix and append the transmittal id
- What roles if required for creating a transmittal?
Answer: to be determined, based on recommendations from JK in his Useability Review
Should we restrict the viewing of unsent transmittals? E.g. only update and above sees pending transmittals
Answer: to be determined suggest yes
- 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
TransmittalRecipient should be user (primary email), email_address or user & email_address
- Keep email address at transmission?
Should TransmittalRevision contain also asset_file_id or separate model (TransmittalRevisionFile)
- Float forms are OK? As at Document and Revision New? Or should we change to table form?
Items to Prototype
- Recipient selection
- Revision and revision file selection
Requirements
- You can send revisions to recipients that do not have a system login
- Sending a transmittal (in the first release):
- Sends an HTML formatted email
- To all recipients
- The email contains a link, with a personalized key, for downloading a ZIP file with all the files
- A audit trail record is made when it is sent
- Once a transmittal is sent it cannot be changed
Means that you can always see exactly what was sent, including the exact copies of all files
- Once a revision file is transmitted, the sent file(s) are are locked
- You cannot change the file, but can change it's metadata
- File versioning is required
- If a transmittal has not been sent, it can be:
- Edited
- Deleted
- Recipients can be added and removed
- Revisions can be added and removed
- You can clone a transmittal
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
- If you want to change a transmittal that has been sent, you have to clone it
- You can re-send a transmittal, to the original recipients, provided nothing is changed
- A audit trail record is made indicating that it was re-sent
- The complete history of transmittal, including canceled transmittals, is retained, including:
- The cover letter
- The revisions
- When a ZIP file is downloaded using an email link, an audit trail record is made containing:
- Date and time
- Recipient identification
- IP address
Transmittal Email
- Transmittal code (automatically generated by the system?)
- Date (set automatically when sent)
- Sender (selected from the user list)
- User must have a role matching the folder (what role?)
- Email subject line, built from:
- Project name/code
- Transmittal code
- Transmittal title
- Transmittal title
- Classification codes
Only classification fields configured in the top block appear in the email
- Possible classification fields (which is configurable by the user)
- Sub-Title
- Description
- Message text
- Table of revisions being sent
- Document code
- Revision code
- Title
- Revision Date
- File information for each file:
- File category
- File type
- File name
Transmittal ZIP Files
- Create ZIP file when transmittal is sent or when the user downloads?
- From the user's point of view the system creates a ZIP file when a transmittal is sent
- From the system point is view it is probably more efficient to generate the ZIP file during a download
- Use file versioning instead of creating ZIP files in order to ensure that the exact transmittal is maintained
Permissions
- Transmittals are stored in a folder
- The folder must be writable by the transmittal sender and the current user
- The files being sent must be readable by the sender and the current user
- If you have permission to read a transmittal:
- You can download the ZIP file, which may include files that you otherwise not allowed to see
- You see the complete file list, but you may not be able to see the detail screens all of them
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
- Code (required. must be unique)
- Name (required)
- Message (optional)
Status (set automatically. pending, in process, sent, canceled)
- Date sent (set automatically)
- Folder (required)
- 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
- All recipients must be registered in the system, with the minimum metadata:
- Must have an email, name, company, description (.g. project position name)
- Description is optional and is not included in the transmittal
- The email address does not need to be validated
- Would be nice to be able to register new recipients while creating a transmittal (perhaps in another window)
- List of possible recipients includes the
- System users (who have logins)
- External (non-system) participants
- All project participants
- Recipients can be selected from:
- The user/recipients list
- Baskets
Selecting Revisions
- Document revisions are sent in transmittals (not files)
- When a revision is part of a transmittal the corresponding document detail page will contain a link it
- The ability to see the link is subject to user's ability to read the transmittal's folder
- Use the basket to put documents in a transmittal
Probably need a refresh basket select list, to allow users to create a basket in a different window
Selecting Files
- Only files attached to revisions can be sent
- Any file and all revision file types can be sent, including both revision and working files
- It is possible to select the file type(s) on an individual revision and file basis
- It may be possible to select or de-select all files for the selected revisions based on:
- File Category, e.g. all revision or working files
- File type
- File format
- Revisions can be added to a transmittal via baskets (lists)
Listing Transmittals
- It is possible to list transmittals
- Sort/search by:
- Title
- Description
- Date
- Sender
- Recipient
- Folder
- Classification fields
Future Release
Implement get the available id button (as a REST transaction) for setting the transmittal code
- Managing download links
- Timeouts. Link no longer works when time limit reached
- Cancel download link for selected recipients
- Promote an external user to be a system user
- Ideally by sending an invitation. Most of the metadata should be already setup
- Transmittal templates
- Transmittal type selects a templates for:
- Email subject line
- Email message
- Variable substitution in templates
- Transmittal type selects a templates for:
- Cover letters in PDF format
- Automatically registered in the system as documents/revisions
- When a transmittal is canceled then it is stored as a new revision
- When workflows are implemented
Check box on transmittal that requires that all workflows of document must be completed
- A transmittal clone is automatically linked to the original transmittal
- References (links) between transmittals can be added or deleted at any time
- Ordering of
- revision files
- recipients
- Cancel transmittal transaction,
- Transmittal status set to canceled
- Inform the original recipients that the transmittal is canceled
- A audit trail record is made indicating that it was canceled
- Subject line has 'CANCEL' at the start
- All keys for downloading the ZIP are blocked. If they are used then the system reports that the transmittal is canceled
- Improved reporting:
- Transmittals and list of file sent to:
- An email address
- A domain name
- List of transmittals that a particular file was sent in
- Transmittals and list of file sent to:
- Transmitting tasks
- A PDF representation of the task, in it's current, is created and registered as a document/revision when the transmittal is sent