Business attachments: manage versions, recovery and access with their records

Managing attachments with business records requires more than storing a file address on a page. Separate the attachment's identity, its file versions and the business references to those versions. Decide which version becomes current after replacement, which version an earlier approval refers to, what deletion and recovery mean, and how previews and downloads enforce access. Establish those behaviors before choosing the storage implementation.

Build the relationship from a business record

Consider a contract as a design example. It may contain a draft, a signed copy and supporting material, each with several revisions. The contract identifier establishes ownership, the attachment identifier identifies the material, and the version identifier identifies one particular file content. A filename helps people recognize a document; it should not be its unique identity.

Suggested attributes include category, original filename, storage reference, size, content checksum, uploader, time and processing state. A checksum helps compare content; it does not establish business authorization. Document these relationships in the software requirements specification, then confirm version views, permissions and recovery within the custom software development scope (Chinese).

Handle the current version and historical references separately

When an employee uploads contract version two, the application may make it current while retaining version one. An earlier approval referencing version one should still open that original file. It must not silently follow a mutable “current file” address to different content. If replacement requires approval again, show the new version as awaiting confirmation rather than inheriting the previous approval.

Concurrent uploads need a decision too. If two people start from version one, the later arrival should not silently displace the earlier upload. One approach is to record which version each update was based on. If the current version has changed, ask an authorized person to reconcile the difference before selecting the effective version.

Amazon S3 Versioning can retain successive versions of an object when enabled. Storage versions do not automatically become contract approval versions. The business application still needs to retain the connection between a particular attachment version and its workflow reference. Verify the equivalent capabilities when using another storage product.

Distinguish deletion actions from recovery actions

Separate unlinking, soft deletion and physical cleanup

Removing an attachment from one record does not necessarily mean no other reference exists. Soft deletion removes it from ordinary use, while physical cleanup can make recovery impossible. Specify who can perform each action, the recovery period, how historical approvals affect deletion and which references must be checked before cleanup.

In a versioning-enabled S3 bucket, an ordinary deletion without a version identifier creates a delete marker; deletion targeting a particular version can permanently remove that version. Do not describe enabled versioning as a guarantee that every accidental deletion is recoverable. Cleanup policies can also affect retained versions.

Recheck ownership and permissions after recovery

When restoring a business record, confirm that the file still exists and that its reference is correct. Recovering an older version can make it the new current selection while preserving the intervening version history and the recovery action. Organization and role assignments may have changed, so determine access using current authorization rather than simply restoring an old list of permitted users.

Control previews, originals and bundled downloads

Thumbnails, converted previews, original files and download archives are all access paths to the material. Test whether copying an address bypasses the business record's permissions. The OWASP file upload guidance calls for validating the uploader's identity and permission to access or modify files, with storage placement selected for business and security requirements. Hiding buttons on a page does not protect a directly accessible download.

Systems that also manage inspection images can refer to linking original images, recognition results and review records. Ordinary contract attachments do not need camera-frame and inspection-event models, however. Establish their relationships around the business objects actually being managed.

Accept delivery with interruption and recovery samples

• If upload succeeds but saving the business record fails, keep a traceable temporary state rather than treating the file as a completed attachment.
• For repeated submissions and concurrent replacement, prevent silent overwriting and identify the effective version and upload history.
• After deletion and restoration, verify the file, business reference and current access scope together. Earlier approvals should still resolve to the original version.
• Before cleaning orphaned files, exclude active uploads, pending processing and objects still referenced elsewhere. Apparent age in a storage directory is not sufficient evidence for deletion.

Handover should include the field relationships, version rules, recovery steps, permission samples and cleanup records. Use a recovery sample containing both business data and files to verify that restored references actually open.