Cannot delete attachments on a cloned object

Question

For our workflows, I'm cloning either tasks or bugs quite often. My issue is that if there is an attachment (video or picture) in the comments of a ticket, and then you clone it, the cloned ticket will have that attachment and I cannot delete it. This is rather frustrating because I don't need the old attachment on a new, cloned ticket. Is this issue known?

Below, you can see my mouse is hovering over the attachment and usually there is a trash bin icon to delete the attachment but here I cannot. This is a cloned ticket (bug) that I just created and the attachment was originally in a comment.

Best,

Drew

Olga Cheban _TitanApps_ · Answer

Hi @Drew Wilson !

The permission angle is already covered above, so I will not repeat it. Worth adding a different option, though, in case the cleanup keeps coming back.

Cloning copies the source work item, so you inherit whatever was on it, including attachments left over from a comment. For work you repeat often, like a recurring bug or task type, that cleanup never really goes away. However, you can avoid it if you use a work item template instead. In this case, new work items will be identical to the clean template, not to an old task where someone already worked before.

For cases like this we use our solution, Smart Templates for Jira. It allows you to save your work item(s) as a template with all its fields, description, and child work items. Then, you can create new Jira issues from that template in a click. Variables handle the parts that change between tickets, such as {{project}} or {{employee_name}}. Nothing from the previous ticket travels along.

Here is what this looks like in practice. This is a work item template we use for onboarding in our team. It includes a set of child work items and checklists (but your template can also consist of just one work item.) Variables are filled in automatically when the work item is created.

I also covered other approaches in my article, Your Guide to Cloning in JIRA: How to Clone Issues in Different Ways. It covers everything from cloning within a project and to another project to automated cloning, bulk cloning, and more. There is a section on the limitations of native cloning and where templates fit better, so it might be a useful read for you.

That's the approach that works for us. Let me know if you have any questions

Gabriela - LeanZero · Answer

The variable probably isn't the space, it's that one attachment, and there's a test that separates the two in about a minute.

Jira splits attachment deletion into two permissions and they behave very differently. "The Delete own attachments permission allows users to remove attachments they've added to a work item." The other is "The Delete all attachments permission allows users to remove attachments from any work item in a space."

Your own description points at the gap. You said you can normally delete attachments "on tickets where I am the reporter", and being the reporter is not what that permission is scoped to. It is scoped to attachments you added. On your own tickets that is usually the same set of files, so the two look identical until something separates them. A clone separates them: you are very likely the reporter of the new ticket, while the inherited attachment was uploaded by someone else on the original. That reading comes from the permission wording, and the clone docs don't spell it out, so treat it as the thing to test.

So here's the test. Attach anything of your own to that same cloned ticket. A screenshot will do. If you can delete the one you added but still not the inherited one, the difference is the attachment's origin and Aaron's space-by-space theory can be set aside for this case. If you can't delete either, then it is the scheme after all and his question about which space you're in becomes the right one.

Either way you'll know which conversation to have with your admin, and "please grant Delete all attachments on this project" is a much easier ask than a general one.

Aaron Pavez _ServiceRocket_ · Answer

That might be true on one space. But all spaces can have different permissions scheme.

This could be the case. If not, let us now if your admin sees everything ok. then we can dig for problems.

Regards