Unable to delete image attachment after removing it via "Select All + Delete" in Description field

Question

Severity/Impact: Medium (leaves orphaned attachments; cannot delete sensitive or obsolete files from the UI without API workarounds)

Preconditions: User has Delete Own Attachments / Delete All Attachments permissions.

Steps to Reproduce:

Open a task/bug and edit the Description.

Paste or insert an image into the Description and save the issue. (Verify the image shows in the Attachments panel without a delete button).

Edit the Description again.

Press Ctrl+A (Select All) and Delete / Backspace to clear the entire description.

Add new text/content and save.

Navigate to the Attachments section on the issue and attempt to delete the previous image.

Expected Result:

Either the image is automatically removed when its inline node is deleted, or the trash/delete icon becomes available in the Attachments panel since it is no longer embedded.

Actual Result:

The image remains listed in the Attachments panel. The delete icon remains hidden, leaving the user with no UI path to delete the file.

Tomislav Tobijas · Answer

Interesting @Ritesh Bhatiya 🤔

I've tried to replicate this on a couple of my instances, but each time I delete an attachment, it's automatically removed from Attachments panel 👀

I guess JRACLOUD-98331 could explain this. I'm curious: does this happen to all users in the instance, or only specific ones? Also, are we talking about a user account that is 'end user' or Jira admin as well? It's not permissions (probably), as others pointed out, but it would be worth considering roles as well.

Also, have you tried checking with Atlassian Support, if you're on a paid plan, to see what they have to say about it?

Cheers,

Tobi

Gabriela - LeanZero · Answer

Hi Ritesh, on top of what Thanasis said, there's also a way to do it from the UI without any API call. The old Manage Attachments page still works on Cloud and it deleted a stuck file for me on a test site today: https://.atlassian.net/secure/ManageAttachments.jspa?key= Each file there gets its own bin icon. Click it, confirm, gone. It's an old page that Atlassian doesn't document for Cloud, so it may disappear one day, and the delete link only shows if you hold Delete Own or Delete All Attachments. I couldn't get your exact steps to leave the file behind while I had the delete permission, because clearing the description removed the image from Attachments automatically. I could only get it stuck when the person who saved the cleared description didn't have attachment delete permission at that moment. Giving it back later didn't help. Atlassian also names edits made outside the editor, like an API call or a CSV import, as another way a file ends up orphaned, so the work item's history might show how that edit was saved.

Thanasis Nikolaou · Answer

Hi, this matches a known Jira Cloud behaviour, not a missing permission. Images pasted into Description are treated as field attachments. By design you can't delete those from the Attachments panel; you remove them from the field (or comment) they were added in: https://support.atlassian.com/jira-software-cloud/docs/delete-an-attachment-on-an-issue/ https://support.atlassian.com/jira/kb/cant-delete-files-from-attachment-panel-in-jira-cloud/ What you're hitting is the orphan case: clearing Description with Select All + Delete removes the inline image from the field text, but the file can stay in Attachments with no bin icon. That's tracked as: https://jira.atlassian.com/browse/JRACLOUD-98331 (There's also a related suggestion to allow panel deletes for field/comment uploads: https://jira.atlassian.com/browse/JRACLOUD-98093) Workaround: delete via REST (Delete Own / Delete All Attachments, which you already have): 1. List attachment IDs: GET https://.atlassian.net/rest/api/3/issue/?fields=attachment 2. Delete the file: DELETE https://.atlassian.net/rest/api/3/attachment/ API: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-attachments/#api-rest-api-3-attachment-id-delete Worth voting/watching JRACLOUD-98331 so a UI fix gets prioritised. Hope that helps!