Class GraphQLAttachmentBlobStore

Not supported from the browser.

Deleting stored bytes is a server-side concern with its own permission and retention rules; a client requesting it directly would bypass them. Returning false leaves the attachment row intact rather than orphaning it against content the client could not remove.

Not supported from the browser, deliberately.

Pulling file bytes through JavaScript only to re-encode them as base64 wastes memory and bandwidth for no benefit — GetDownloadUrl gives the browser something it can hand straight to an <img>, a download, or a fetch, and the service falls back to exactly that when this returns null. This is the one operation where "not supported" is the better answer rather than a gap.

Mints a permission-gated, time-limited URL for a stored file.

Goes through CreateMediaAccessToken rather than CreatePreAuthDownloadUrl: the latter is keyed by storage account + object name, so using it would mean the client resolving storage internals it has no business knowing. The media route is keyed by MJ: Files id, checks the caller's permissions server-side, and Range-streams — it is the same path mj-storage-media-player already uses, so this adds a caller rather than a second mechanism.

This is what makes the write path readable. Explorer only started producing storage-backed attachments when this seam was bound; without a URL here, every attachment over the inline threshold would upload successfully and then be permanently undisplayable.

Uploads bytes through MJAPI's storage subsystem, which creates the MJ: Files record.

Storage account selection is the server's decision here: a browser has no business choosing a storage backend, and UploadFile resolves a default when none is named.