Note
We've packed up and moved from Confluence to Discourse to bring you a better, more interactive space. Out of courtesy we didn't migrate your user account so - you will have to signup again
The Exalate team will be on holiday for the coming days - returning Jan 4
Enjoy & stay safe
Hi,
In our Exalate - Jira configuration we have a syncing rule we have internal syncing data.
We have in our company R&D developers and agents that support customers.
The workflow is: a customer opens a ticket, the agent gets it and he decides if R&D is needed.
If yes, he opens a new ticket to R&D that is synced with the original customer ticket.
The sync allows R&D to see all the history of the customer request.
Although the sync includes attachments and comments, we have a problem with it. To prevent infinite syncing, we were advised to add a prefix "CON_" to the attachment file names. This addition makes a mess in the attachment list of the issue, and the users don't like it too much. Beyond that, renaming the file disrupts the preview of thumbnails in the issue comments.
Is there another way to prevent infinite syncing without renaming the files? Maye be changing a different property of the attachments?
Thanks
Hello, Elyashiv , as far as I understand, your sync set up was following this guide: https://docs.idalko.com/exalate/x/xoCKAg
And according ti this picture,
the addition of the file prefix happens in the Internal Service Desk issue, right?
Later on on the same instance you use these prefixes to avoid syncing attachments from Dev A to Dev B and visa-versa, correct?
If all of my suggestions were right so far, might I ask you to share the outgoing sync scripts that you have on the Internal Service Desk side, please?
I'll suggest a script that doesn't rely on file prefixes but instead uses Exalate's own sync metadata to make sure it doesn't sync the wrong attachments over.
Regards, Serhiy.
Hi Serhiy Onyshchenko ,
Your suggestions are correct, this is our case.
This is the relevant code from the relevant rule of the outgoing synchronization of attachments:
And this is the relevant code from the incoming sync rule:
We have a few internal syncing rules and in each one, we have a different prefix: "CON1_" "CON2_" etc.
Hey, Elyashiv ,
instead of filtering by filename, we could use internal sync link metadata which describes, how attachments and comments relate to one another...
Please, try replacing (in Outgoing sync) your current :
with
And for Incoming sync, replace:
Note that I used TEST-1 as an example, replace it with an issue key which you'd like to test this out on
Regards, Serhiy.
Hi Serhiy Onyshchenko,
Thanks for your answer!
Unfortunately, it didn't work as expected.
R&D ticket (Dev A) didn't get the attachments at all - from the customer ticket (Internal SD).
Hi Serhiy Onyshchenko ,
Do you have any other solution?
Thanks
Hello, Elyashiv , sorry for being so slow on turn around. Feel free to ping Saskia so that she chases me
Let's troubleshoot if the suggested approach can work
Hi Serhiy Onyshchenko ,
The script didn't run until the debug line.
It stopped with error:
referring to the line:
Huh, let's try and fix that:
Please, let me know, how that goes.
Hi Serhiy Onyshchenko
this is the error now:
Hi Serhiy Onyshchenko ,
We still have an issue.
referring to this scheme:
If we add an attachment to the "Dev A" issue (using a comment or regularly attaching an attachment to the issue) we will see it in all connected issues (Internal Service Desk + Dev A + Dev B).
We are supposed to see the attachment only on "Dev A" & "Internal Service Desk" issues. Any other "Dev" issues are not supposed to get the attachment.
I will add that if you comment "Dev A" you will see the comment only on the "Internal Service Desk" issue.
Can you assist?
Hey, Elyashiv , seeing my snail-speed at helping you, let me take another approach and take my time to set it up in my env to give you a video and full description of the set up to get it working. Let me get back to you with an update on this Monday Jan 17th.
OK Serhiy Onyshchenko
Thanks.
Hey, Elyashiv , a small update: got the case setup, starting to run the debug.error I suggested earlier to see what I'll find.
Let me give an update on my findings Tomorrow
Hey, Elyashiv
So the suggestion with the traces doesn't seem to work, as Exalate creates traces after attaching the attachments. I'll be looking into other places - entity properties. Let me come back to you on Thursday with an update.
Hey, Elyashiv , looking into options to store multiple records for the issue so that Exalate knows that a certain attachment comes from a certain connection.
Currently exploring this option:
https://docs.atlassian.com/software/jira/docs/api/8.13.16/com/atlassian/jira/entity/property/EntityPropertyService.html#setProperty-com.atlassian.jira.user.ApplicationUser-com.atlassian.jira.entity.property.EntityPropertyService.SetPropertyValidationResult-
Regards, Serhiy.
Hello, Elyashiv , let me give you an update on Wed 26ths re the entity property option
Hey, Elyashiv , apologies for delayed update, the property service approach bears fruit - already able to note stuff to the issue property before the attachments are actually attached to the issue. Next update on Tue Feb 1st.
Hi Serhiy Onyshchenko ,
I will wait.
Thanks in meantime.