Attachments and storage

Every file a user uploads in orboto - on a ticket, a doc, or a comment - lands in object storage (S3-compatible; RustFS locally in development) with a matching database row that tracks who uploaded it, its size, and what it's attached to. Admin -> Attachments is the single workspace-wide view across all of that, independent of digging through individual tickets or docs one at a time.

The attachments list

Each row shows the filename (with its content type), size, used in - a link straight to the ticket, doc, or comment it's attached to, with the parent project or doc space named alongside it - uploaded by, and uploaded at. The header shows the total storage size across every attachment currently in the workspace.

Filter by:

• Filename search - free text.
• Type - Tickets / Docs / Comments / all.
• Orphaned only - see below.

Delete any attachment with the trash icon; the confirmation wording differs depending on whether the file is currently in use (deleting it will visibly remove it from wherever it's attached) or already orphaned (nothing else references it, so deleting it is pure cleanup).

What "orphaned" means

An attachment becomes orphaned when the database row that recorded "this file belongs to that ticket/doc/comment" is gone, but the underlying object in storage never got cleaned up alongside it - most commonly the parent ticket, doc, or comment was deleted through a path that didn't (or couldn't, due to a partial failure) also remove the file. An orphaned row still shows up in this table (with an amber warning badge instead of a working "used in" link) but represents storage you're paying for with nothing in the product actually pointing to it.

Toggle orphaned only to see just these - useful for a periodic cleanup pass, or right after a data-import that may have left stray references behind.

Orphaned storage: objects with no database row at all

A second, more subtle category exists one level deeper: storage objects in your S3-compatible bucket that have no attachment row whatsoever - not even an orphaned one. This can happen from an upload that completed in storage but failed to record its database row (a partial failure mid-request), or from an interrupted delete that removed the row but not the object. When orboto detects any of these, a banner appears at the top of the page reporting how many such objects exist and their combined size.

Click Delete orphaned files (with the confirmation naming exactly how many objects will be removed) to delete every one of them from storage. This action only ever touches objects that have zero database reference of any kind - it can never remove a file something in the product still points to, orphaned-row or not.

Troubleshooting

• A file I deleted from a ticket still shows up here - if it shows as orphaned (amber badge, no working link), the underlying storage object wasn't cleaned up when the reference was removed; delete it directly from this list to finish the cleanup.
• The orphan-storage banner keeps reappearing after I reclaim - a fresh interrupted upload or delete can create new orphaned objects at any time; this isn't a sign the reclaim itself failed, it's new orphans accumulating since the last pass. Check the reported count and size each time rather than assuming it should reach zero and stay there.
• Total storage size doesn't match what I'd expect from active tickets/docs alone - it's computed over every attachment row in the unfiltered set, including any orphaned rows still listed here; filter to orphaned only to see how much of the total that accounts for.
• A delete failed - the error message from the failed attempt is shown directly; a common cause is a storage-layer connectivity issue rather than anything about the specific file, so retry once storage is confirmed reachable.