nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SYNC Attachements between 2 tickets. MULTIPLICATION files issue for ticket B. AUTOMATION

Mateusz Janus_emo9ao

Brothers & Sisters,

I see there is already a BUG in jira regarding SYNC comments with attachements but there is workaround proposal that I am trying to use.

SYNC attachements.jpg

Its simple logic taken from official atlassian web side.

1. When ticket is edited -> field Attachements

2. Issue type condition

3. For linked issues type XYZ

4. EDIT field Attachements -> Copy From trigger issue

5. Add a smart value comment

ISSUE OF THIS SOLUTION I AM FACING

1. I have Ticket A as a source of attachements

2. Ticket B that should copy attachements from Ticket A once they are uploaded to ticket A

In Other words, when Ticket A has new attachement copy it to Ticket B

BUT!!

1. This solution works only for 1 TIME sync.

2. If I upload Attach1 to Ticket A -> Attach1 is copied to Ticket B (PERFECT)

3. If I upload Attach2 to Ticket A -> Attach2 IS copied to Ticket B but also Attach1 is copied again

at the end of this Ticket A has 2 attachements and Ticket B has

Attach1 x2

Attach2 x1

If I upload Attach3 to ticket A then again Ticket B will take all of attachments AGAIN + Attach3.

Ticket B does not recognise "NEW ATTACHEMNT" from Ticket A.

I believe its common issue and i am wondering if it is feasible to resolve with automation only....

Accepted answers

Arkadiusz Wroblewski

@Mateusz Janus

That behavior is exactly what I’d expect from that setup.

The key point is: “Copy attachments from trigger issue” is not a delta-sync. It’s a full copy. Every time the rule runs, Jira just grabs everything from Ticket A and applies it to Ticket B again. Jira Automation doesn’t have the concept of “only the newly added attachment”, so Attach1 gets copied again when you add Attach2, then again when you add Attach3, etc. That’s why you end up with duplicates.

And you’re also right about the trigger problem: there isn’t a clean “Attachment added” trigger (especially in DC) that lets you reliably catch just the new file and act only on that one.

So if you want to solve it, you’re basically choosing between two realities:

“Mirror mode” (automation-only, stable):

Before copying, delete attachments on Ticket B, then copy from Ticket A.

Result: no duplicates, but Ticket B becomes a mirror and you’ll wipe anything extra added directly to B.

“True sync” (only copy what’s new):

That needs scripting / app logic. You need something that can compare attachment lists and copy only the missing ones. Automation alone can’t really do that cleanly.

So short version: automation can mirror, but it can’t do real incremental attachment sync without duplication.

All comments

Florian Bonniec

Hi @Mateusz Janus

I do not have a DC version on hand for now, but instead field change on attachment is there an event Attachment added instead ?

Regards

Mateusz Janus_emo9ao

hi @Florian Bonniec i was thinking about same. Differente trigger but there is no dedicated trigger for attachements.

There is generic "issue updated" but dont know how to use this trigger tbh

Florian Bonniec

Nothing available in Multiple issue events too ?

Arkadiusz Wroblewski

@Mateusz Janus

That behavior is exactly what I’d expect from that setup.

And you’re also right about the trigger problem: there isn’t a clean “Attachment added” trigger (especially in DC) that lets you reliably catch just the new file and act only on that one.

So if you want to solve it, you’re basically choosing between two realities:

“Mirror mode” (automation-only, stable):

Before copying, delete attachments on Ticket B, then copy from Ticket A.

Result: no duplicates, but Ticket B becomes a mirror and you’ll wipe anything extra added directly to B.

“True sync” (only copy what’s new):

That needs scripting / app logic. You need something that can compare attachment lists and copy only the missing ones. Automation alone can’t really do that cleanly.

So short version: automation can mirror, but it can’t do real incremental attachment sync without duplication.

Mateusz Janus_emo9ao

cześć @Arkadiusz Wroblewski

thanks for response

"mirror mode" - so u suggest to add another action "remove all attachments" in ticket B and then "COPY ATTACHEMENTS" from ticket A ??? quite clever to be honest

"true sync" - i have scriptrunner but i am total NOOB with groovy and i can write only very simple scripts

Mateusz Janus_emo9ao

@Florian Bonniec

i do have multiple issue events. What is your idea regarding this trigger?

Arkadiusz Wroblewski

Cześć @Mateusz Janus 🙂

Yep for mirror mode that’s exactly what I mean, and it is kind of a clever hack in Cloud/DC terms:

Branch to Ticket B → remove attachments on B → then copy attachments from Ticket A.

Result: no duplicates, always clean. Only downside: Ticket B must be a “follower” anything attached directly to B will get wiped on the next sync run.

For true sync: don’t stress about being a Groovy pro. You’re right, this is one of those cases where automation just can’t do “delta”, so ScriptRunner is the right tool. And the script logic is actually pretty simple conceptually:

read attachments on A

read attachments on B

compare (name/size is usually enough)

only upload what’s missing

Runned as Script Listener when conditions meet.

🤠

Mateusz Janus_emo9ao

@Arkadiusz Wroblewski for quick win solution I shoose MIRROR remove all attach and upload again full list. Maybe one day Script Runner gonna be my new friend BUT NOT TODAY : D

The problem is... I am just checking list of available ACTIONS and I do not have action like "DELETE ALL ATTACHEMENTS"... so how to remove them?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-data-center

attachment

data-center

sync