Attachment Policy

The Attachment Policy contains all system wide settings for Attachments which determine Attachment behavior. Unless an Attachment Element specifically identifies a Repository and a node, this Attachment Policy is examined across all nodes until a rule is found to match the charateristics of file being attached. These rules can qualify where a file will be stored depending on classification, type, size, department, and file name. The system uses a scoring mechanism to match your file to a storage repository. All rules are evaluated and scored. Each time a match is found it improves its score and then the system takes the one with the highest score. If both have the same score then it uses the order of your rules and chooses the first on the list. If no matches, it defaults to the network repository and sapphire custom node.

Property Name Description
Attachment Classes and Rules Specify criteria for how, when and where to store Attachment files. Define rules with different criteria to control which repository is used to store different types of files.

For example, if the file is a video, store it on the local network and do not zip the file. If the file is a word document, store it in an AWS Repository and encrypt the file.

ValueDescription
Rule Id

Identifier of the rule.

Match by ClassIf an attachment has been associated to the specified classification, this is a match. As stated above, LabVantage scores by number of matches to determine the destination repository for each attachment.

Attachment Classes are defined in the AttachmentClass Reference Type. Click the arrow to navigate to the Reference Type page where you can manage the AttachmentClass Reference Type.

Match by File Type

File Type for which you are defining this rule such as Image, PDF, PPT, Excel and others.

Match by File Name

The name of the file for which you are defining this rule. You can use glob syntax.

Match by Minimum File Size

File Size in megabytes. Anything above the size entered will be matched.

Match by Security Department

When an attachment is created, the security department for the attachment is inherited from the record to which the attachment is being made. This happens only when departmental security is enabled on the primary record.

When copying down the department to a data capture, the security department of the instrument is used. If departmental security is not enabled (or not assigned) for the instrument, the testing department is used. If this is also null, the collector security department then the testing lab of the collector is used.

File Repository Id

If this rule is chosen according to the above matches, the File Repository identified here is used for storage.

File Repository Node

The name of the node in the above File Repository Id. Example: "Sapphire Custom"

Encrypt

"Yes" encrypts the file. If the Repository does not suppport encryption, the Attachment is encrypted prior to storage.

Zip

"Yes" compresses the file prior to storage.

Content Versioning

"No" makes any attachments referencing this class non-editable in the Attachment Page.

For information regarding this functionality, see Attachments → Attachment Types → File.
Phrases for Rich Text Allows Phrases to be used in "Rich Text" Attachment Types.
ValueDescription
Phrase TypeDefines the Phrase Types that will be available through the "Insert → Insert Phrase" menu item in the Formatted Text Editor for Attachments.
Phrase LookupLookup page that opens through the "Insert → Insert Phrase" menu item in the Formatted Text Editor for Attachments.
Maximum Upload Size Maximum size of an uploaded file (in Mb). If this is not set, the servlet initialization parameters are used. If those are not set, this defaults to 10 Mb. Set to -1 for unlimited size.

This can be used to selectively restrict file size on a per-Element basis. For example, suppose an SDI Maintenance page contains two attachment Elements: one for SOPs, and another for Instrument files. You could then set the maximum size for SOPs to 1 Mb, and the size of the Instrument files to 10 Mb assuming each leads to a different node of this attachment policy.
Thumbnails Determines if (or how) thumbnails are displayed:
ValueDescription
Generate and StoreGenerates thumbnails and stores them against the Attachment for caching.
Do Not StoreGenerates thumbnails but does not store them against the Attachment for caching. This reduces viewing and download performance.
Show if AvailableDoes not generate or store thumbnails, but will show a thumbnail if it is already available.
DisabledDoes not generate or store thumbnails.
NOTE: The "Thumbnails" property is available in LabVantage 8.4.1 and higher LabVantage releases. Any migrations to LabVantage 8.4+ from earlier versions will not have a thumbnail image generated by default. One of the reasons for this is to preserve audit history. When thumbnails are added to SDIAttachments, the modification date is updated. You can either choose to have these thumbnails generated during an upgrade (which affects the moddt), or wait until a modification is made to an attachment which will also generate a thumbnail.
Local Caching

"No" prevents any local server from caching files. The default behavior is "Yes". Disabling caching here will override the setting you have in the Repositories that use this policy node. When "Yes", each time an Attachment is viewed or downloaded it is cached locally on the application server. If the Attachment is modified, the cache is cleared. If the file is compressed, decompression is performed on the cache, keeping the optimized version available for use.

Caching is particularly useful for repositories like AWS and database where there is an overhead to download the file from the external source. However, if the Network file repository is local to the server (stored on the same box), then caching is not recommended as you are getting nothing from it unless the files are zipped. However, if the network store is over a slower connection, then caching may be used to improve performance. The general recommendation is if it is a local file system then disable caching. If not, enable caching.
User Role For Attachment Revisioning Allows users who have this role to promote/copy an older version of an attachment to the next higher and current version of the attachment. If no role is identified, all users can make older versions of an attachment the current version. See Attachment Revisions
Admin Role For Attachment Revisioning Role required for clearing a lock that was placed on an attachment by another user. If no role is identified then no role is required thus allowing all users to clear other user's locks. See Attachment Revisions
Max Hash Size In MB. Defaults to 100 (megabytes). Any file larger than this will not be hashed. Set to 0 to stop hashing for all attachments using this policy node. Set to -1 to hash all files regardless of size.