User Attachments

Some user records need supporting documents kept alongside the researcher's profile — a signed reading-room agreement, a scanned ID, a copy of a letter of introduction, or a permission form. Aeon stores these as attachments on the user record, in the database itself, so they travel with the user and aren't scattered across staff machines.

Most user records have no attachments at all. You'll only open the Attachments tab when you have a file to keep on a specific researcher, or when you need to retrieve one a colleague saved earlier.

When you'll use this

• A researcher hands you a signed form or document you want to keep on file — attach it to their record.
• You need to look at, download, or print a document someone attached earlier (for example, to confirm an agreement is on file before clearing a researcher).
• A document is outdated or was attached by mistake — replace it with a new copy, or delete it.

This works in the web client now

In earlier versions of Aeon, user attachments could only be managed from the desktop client. In Aeon 7 you add, view, download, and delete user attachments directly in the web staff client. Files attached here are stored in the same place as before, so attachments added in either client are visible in both.

Opening the Attachments tab

1. Open the user record — search for the researcher and open their record, or click them from anywhere their username appears (for example, jdoe).
2. In the user record's tabs, click Attachments. The tab label shows a count of how many files are attached, so you can tell at a glance whether a record has any.
3. The tab shows two stacked sections:
   • Attachments — the files currently on this user, one row each.
   • Attachment History — a running log of every attachment added, updated, or deleted for this user.

If the user has no files yet, the Attachments section reads No attachments, with a prompt to "Click Add to attach a file to this user." The Attachment History section shows No attachment history until the first action is recorded.

What's shown for each attachment

The Attachments list shows one row per file, with these columns:

Column	What it shows
File Name	The original name of the uploaded file.
Size	The file's size.
Modified	When the file was last added or replaced.
Modified By	The staff member who last uploaded or replaced it.

Each row also has two icon buttons at the right: a download icon and a delete (trash) icon.

Adding an attachment

1. Open the user's Attachments tab.
2. Click Add (top-right of the Attachments section). Your browser's file picker opens.
3. Choose the file and confirm. A brief progress indicator shows on the Add button while the file uploads, and on success Aeon shows an "Attachment uploaded" confirmation. The new file appears in the list and a matching entry is written to Attachment History.

Allowed file types and size

Aeon accepts these file types as user attachments: PDF, DOC, DOCX, and images (PNG, JPG, JPEG, GIF, BMP, TIFF, WEBP). If you pick anything else, the upload is refused with a message listing the allowed types. Each file can be up to 25 MB.

Replacing a file with the same name

If you upload a file whose name already exists on this user, Aeon doesn't create a duplicate — it offers to replace the existing one. An Overwrite Attachment dialog appears:

A file with the name <filename> has already been attached to this user's records and will be overwritten.

• Click Overwrite to replace the existing file with the new copy. The Modified date and Modified By update to reflect the change, and Attachment History records that the file was updated.
• Click Cancel to leave the existing file untouched.

To attach a different version without overwriting, give the new file a different name before uploading it.

Adding from the toolbar

You can also start an upload from the Attach action in the user record's action toolbar (the paperclip). It opens the same file picker as the Add button on the Attachments tab.

Viewing or downloading an attachment

In the Attachments list, click the download icon on the file's row. Aeon retrieves the file and saves it through your browser; open it from there with whatever application handles that file type.

Some older files can't be downloaded

For security, Aeon only serves the allowed file types listed above. If a record carries a file of a now-disallowed type — for example, something attached long ago through the desktop client — the download is blocked with a message that the file type can't be downloaded. Newly attached files are always one of the allowed types, so this only affects legacy files.

Deleting an attachment

1. In the Attachments list, click the delete (trash) icon on the file's row.

2. A Delete Attachment dialog asks you to confirm:

   Are you sure you want to delete <filename>? This action cannot be undone.

3. Click Delete to remove the file, or Cancel to keep it. On deletion Aeon shows an "Attachment deleted" confirmation, drops the file from the list, and records the removal in Attachment History.

Deletes are permanent

Deleting an attachment removes the file from the user record and the database. There is no undo, and the file itself is gone — only the history entry noting the deletion remains. Download a copy first if you might need it later.

Attachment History

The Attachment History section below the file list logs every attachment action for this user, newest activity included as it happens. Each entry shows:

• Date — when the action occurred.
• Entry — what happened (for example, an attachment being updated or deleted).
• Staff — the staff member responsible.

These same events also appear in the user's overall change history, so attachment activity is auditable whether you're looking at this tab or the user's full history.

Permissions

• Viewing the Attachments tab and downloading files is available to any staff member who can open the user record.
• Adding or replacing an attachment requires the Edit level of the Users permission. If your role is view-only for users, the Add and Attach controls are unavailable.
• Deleting an attachment requires the Full level of the Users permission — a higher bar than uploading.
• While a user record is locked by another staff member, the toolbar Attach action is disabled until they're done.

Editor review — remove this callout (and the HTML comment below it) before publishing

A couple of points an SME should confirm on this page:

• HELD ON BUG #191. A field-restricted role (e.g., View Only with Contact Information / User info restricted) gets a 500 — red "Failed to load attachments / history" — on the Attachments tab, because the global FieldRestrictionFilter crashes the attachments/history response instead of masking fields (confirmed: removing the field restrictions makes it load). So this page's Permissions claim — "anyone who can open the record (Users View) can see attachments" — is correct by code/design but does not hold for field-restricted roles until #191 is fixed. Open product question (also in #191): confirm whether Users: View is the intended rule for viewing attachments, or whether attachments should be restricted for some roles (in which case they should hide cleanly, not 500, and this permission sentence would change). Full write-up in Documentation-Working-Directory/Bug Reports/. Do not finalize until #191 is resolved and the intended rule is confirmed.
• Per-row delete vs. permission level: the trash icon is always shown on each row, but the delete itself requires Users Full (the API enforces it). Confirm whether view/edit-only staff should see a disabled trash icon, or no icon — current copy says deleting "requires Full," which matches the API gate but not necessarily the on-screen affordance.
• Screenshots needed: (1) the Attachments tab showing the file list + Attachment History; (2) the Overwrite Attachment confirmation dialog.

The full generation metadata — sources, files read, and verifications a tool like Claude would need to regenerate this page — is in the HTML comment directly below this callout. When this page has been reviewed and approved, delete both this callout and that comment; a page with no Editor-review callout is one that's done.