Creating a routing or 'passthrough' style project

[Zach Taylor]

I am not an Atlassian expert, though I am learning more and more each day. 

I'm working on a setup where tickets are created in a company-wide externally-facing project (e.g., “External Project”) but need to be cloned into an internal team-managed project for processing. Once fully cloned, the original ticket should be immediately deleted so that customers only see the internal ticket (e.g., “Transportation”, "Finance") in their portal. This way the client has only a single project to navigate, but it appears that they dropped the ticket into the correct internal project.

We use Deep Clone and I have added a post-function to the creation step of the workflow which correctly recreates the ticket in the internal project, including any forms. JIRA automation immediately deletes the original ticket on creation.

The challenges I'm facing are:

1.Race Condition with Forms: If the original ticket is deleted too quickly forms don’t clone into the internal project. If I don't delete immediately, the form is correctly copied. 

2.Redirect to Deleted Ticket: After ticket submission, JSM redirects the customer to the original ticket where they may wish to comment or share with others. (e.g., EP-12), but this ticket no longer exists or will be deleted in moments. Customers should only be directed to the one associated with the internal project (e.g. TT-15).

How I've tried to solve it:

1. We don't pay for Premium so I can't add a Delay step of say 10-15 seconds to allow the form to be copied then delete the "external" ticket. I don't know if Premium would be approved as it more than doubles our cost. I also thought to use an SLA timer, then delete once the SLA is breached, but the shortest time an SLA can be is 1 minute, which is too long for my purposes.

2. chatGPT tried to guide me through creating a screen with a read-only field, and  associating it with the creation step, but I was unable to figure out exactly how. I'm going to try and attempt that again in a slightly different way. Would upgrading to Premium make any difference in trying to solve this?

Thanks to anyone with some insight!

[Luka Hummel - codefortynine]

Hi @Zach Taylor

Thank you for using Deep Clone for Jira!

I can help you with your first challenge.

You can use Deep Clone to delete the issue after cloning. We have created a relatively detailed guide how to do that here. Alternatively can just use multiple "Re-fetch issue data" actions. Each should delay the automation by a couple seconds. This was the old workaround from before the "Delay" action was added. Rather imprecise but it works :) 

Regarding your second challenge:

I don't think a redirection like you envision is possible in Jira Cloud. The closest you could do is clear all the values of the old issue. Set all fields to read-only and let an automation comment the link to the new issue in the old issue.

To get everything to be read only you can convert the issue to another issue type where the associated screen scheme has no issues in the CREATE and EDIT screens. You can find more on that here.

You can also use Deep Clone to trigger the comment before deletion (or other actions) with the Incoming Webhook feature, as described above.

[Zach Taylor]

Thanks @Luka Hummel - codefortynine
I love using Deep Clone for its features and flexibility!

I have tried to reply twice now to this answer and it hasn't stuck. Hopefully third time is the charm.

1. Using 15 re-fetch steps in a row does give me an 8-10 second delay, but I like the idea of a webhook as it would guarantee the correct order of operations. Thank you.

2. Does this mean that the "landing page" customers are presented with would only have the minimum number of fields and be read-only? I'm trying to prevent them commenting on an issue that's already deleted or will be deleted in short order. I have already removed sharing with their org, so that's not a concern. 

I'll try to get the read-only screens, etc. setup. Thanks

[Luka Hummel - codefortynine]

Thanks for the praise :)

2. To limit the ability to comment, you can edit the status you are using for the original issue after cloning.

• Go to Project Settings > Workflow (The one that is associated with the request type and issue type)

• Edit > Click on the relevant status > Properties

• Add the following

  • Property Key: jira.permission.comment.denied

  • Property Value: true

• Publish workflow.

You can find more information on that solution here.

[Zach Taylor]

This might work. As long as customers get the ticket overview on creation, but can't comment on it or edit it in any way, I can name that status 'Processed' since they see that status, and have it comment the link to the internal ticket. Then once they click away, they will see their Deep Cloned ticket in their requests.

I will try that today, thanks.

[Zach Taylor]

I tried to use this today, but am struggling with the webhook actually working properly. It failed as a post-function so I started doing it manually and calling the webhook that way. Unfortunately, the webhook never seems to fire as the audit logs never even show it running. 400 is a pretty generic error, trying to dig deeper. It feels like I fell down the rabbit hole!

[Zach Taylor]

I tested using Bruno and an http POST request and was able to confirm the webhook is working correctly. I don't see where you can input the secret the webhook requires into the Deep Clone application, so I think that may be why it's failing. 

[Zach Taylor]

@Luka Hummel - codefortynine I'm very close. Manually calling the webhook does what I need, but I need Deep Clone to properly call that webhook. Then I believe I will have accomplished my goal. Thanks for your help with all of this!

[Luka Hummel - codefortynine]

Hi @Zach Taylor

You are correct. The secret is missing. This appears to be recently added by Atlassian.

Luckily, you can simply add the secret to the URL path in this format:

[Webhook URL]/[Secret]

I updated the documentation to reflect this change.

[Zach Taylor]

Thank you @Luka Hummel - codefortynine I appreciate you updating the documentation as well. I had even tried to use a slash before the secret, but chose the wrong one based on some of Atlassian's documentation. 

Now I have an interesting problem your team may want to know more about. Deep Clone reports success when calling the webhook whether during the post function or manually, but the audit log of the webhook shows that it never ran... The expected action of the webhook (commenting on the ticket) doesn't happen.

You'll note the times of the jobs and the lack of corresponding action in the JIRA automation auditlog. Where do we go from here? Would you be interested in a meeting to discuss it further?

Thanks

[Zach Taylor]

Meant to include the automation rule details also:

[Zach Taylor]

I have submitted a formal support ticket, ATLAS-7802. Thanks.