Attachments preview (uploaded in custom fields) no more visible in a created ticket through JMWE app

[Reply Test Group]

Hi Jira Community and Jira Misc Workflow Extensions team,

to satisfy our customer's request to have custom fields that can also contain attachments (therefore not using the "Attach" command), it was necessary to create multi-line text fields with the render set to [Wiki Style Renderer] (in "Description" field style, so to speak), so as to have the "Files & images" function to upload files and "bind" them to the respective field:

Subsequently we implemented an automation with the JMWE app with which, once a type A ticket has been closed, we create a type B ticket by overturning many of the former's fields on the latter, among which there are the custom fields for the attachments (highlighted in yellow) mentioned above.

This allows us to create new tickets by inheriting the uploaded attachments in the respective fields (the Attachment field highlighted in blue is necessary for this operation).

However lately (I would say from the beginning of April), this work-around seems to no longer work because, once the tickets have been created, the previews of the files inserted in the fields in question are not visible:

It happened even before, every now and then, but reloading the page the problem disappeared.

Now, however, not even doing Ctrl + F5, or clearing the browser cache, can you return to the previous situation. Previews were needed to instantly know which attachment belonged to which field.

We also use Nunjucks scripts to retrieve the aforementioned fields and correctly flip them into those of the new ticket:

, but even in this way we no longer see previews, for a few days.

We don't know if it is a page rendering problem that takes too long to load the previews of the files, or if the numerous automations present somehow burden the loading of the ticket.

If anyone from the JMWE team knew more, it would be of great help to us.

Thanks,

Fabio

[David Fischer · Accepted solution]

Hi @Reply Test Group 

I'm actually pretty sure it's a bug in the New Issue View, but an easy way to check is to go to the old issue view and check if it works there. Let me know your findings. 

David

[Reply Test Group]

Hi @David Fischer ,

can I return to the old issue view? It seems to me that this new view it's a "no way back" implementation, on cloud at least..

Anyway, I'm pretty sure that I created the functionality explained above during the New Issue View period, so it's possible that now the only field that allows you to insert files in it, in the way I want to use them, it's the Description one.

But, if you know the possibility to return to the old issue view (and if you tell me how to return it), at least I could try it and see if in the old one it works (again).

TY,

Fabio

[David Fischer]

Hi Fabio,

Atlassian just disabled the setting that used to be present on the Personal Settings page. However, you can still go to the old issue view by adding ?oldIssueView=true to the issue view URL. For example:

https://myinstance.atlassian.net/browse/TEST-2?oldIssueView=true

[Reply Test Group]

Ty @David Fischer for the help, but I never worked with the old slyle view and surely I create my functionality in the new one.

Anyway, the old view didn't work in the same way: the only implemented preview is on the images, and for files I see only a link to those.. but if I click them, I can reach them via link, so in some way the new style view renders the file throught previews that can have problems passing from one ticket to another, when the old style view focuses only on the files link for a better functionality:

Well, if now I could reach the name and the content of the files that I put in those fields, maybe the preview problems still remain but at least I should have a link under those previews that bind the users to the respective files.

I'll try it..

Bye,

Fabio

[Reply Test Group]

No one from JMWE app? @ajmweb @jmwendt @Jmwendwa ...

Thanks,

Fabio

[David Fischer]

Hi Fabio,

so this confirms that it's a Jira bug in the new issue view. As you can see, in the old issue view, the attachment is recognized and presented as a link. In the new issue view, the attachment is also recognized but not displayed properly.

I believe I know why this bug is happening: the new issue view handles attachment references differently. When it receives content (wiki text) that includes a reference to an attachment, it tries to find the attachment immediately and if it doesn't find it, it creates an invalid representation like the one you're seeing. And since you're creating a new issue, the attachments don't yet exist (they can only be added after the issue is created) when the value for the custom field is passed to the Jira REST API by JMWE.

The old issue view, on the other hand, doesn't look up the actual attachment until it actually displays the custom field, and by that time, the attachment is already added to the issue.

The workaround would be to copy the text fields after the issue is fully created and the attachments are copied. For that, you need to put the Create Issue(s) post-function in a "Sequence of post-functions" post-function, followed by Copy Field Value to Related Issues post-functions to copy the wiki text fields (such as UI Attachment)

Of course, you can also reach out to Atlassian to report the bug, but I doubt they will do anything about it.

David

[David Fischer]

By the way, this is a known issue: https://ecosystem.atlassian.net/browse/ACJIRA-2175

[Reply Test Group]

Hi @David FischerI've done it!

Through the post function on the Create transition of the ticket to be created, I applied a delay of 5 seconds on the start of the creation phase, and then take the fields I need from the last issue added with the 'related to' relationship:

Just in case, I added this post function after all the default system post function..

Now I must create a check to verify whether the creation comes from my own process or from the cloning one with the 'Clone links' checked, but I've already the solution ;)

Thank you,

Fabio