Transfer content for predefined fields before creating a request

Thomas Balasch December 15, 2017

Hello,

currently I have a scenario where I need to set predefined fields for a costumer request beeing created in the service desk portal (Service Desk 'B'). The content for those fields exists in another issue from another service desk (lets call it 'A'). 

Furthermore the user should be forwarded/redirected from 'A' to 'B' in some way. Possibly via a link in 'A' or a costum-mail with a link to the costumer request in 'B'.

The big issue I have with this constellation is, that I need set those fields VISIBLE for the costumer, so the ticket he is creating, is partially filled. The newly created issue ('B') has then to be linked to its trigger issue ('A').

I allready tried to gain this functionality by using 'Automation', 'Jira Misc Workflow Extensions' and 'Actions for Jira', which work only in some parts. For example I tried adding the fields to the current request in 'A' by usinf 'Actions', but multiselect fields look just horrible. So I haven't found a solution so far and am somewhat out of my depth right now. I can't waist all my time on trail and error at the moment.

To summarize it: User gets link for 'B', field-contents get transfered from 'A' to 'B'. The request form in the portal ('A') is now partially filled. The user fills the missing fields and sends the request. The request gets linked to the one from 'B'.

Maybe someone had a similiar problem and was able to fix it.

Cheers, Thomas.

1 answer

0 votes
Huw Evans
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 17, 2017

Hey Thomas,

This sounds like exactly the sort of thing that Automation was created for—with a few tweaks to what you've already tried, you should be good to go.

I chose to set up my rule like this:

Screen Shot 2017-12-18 at 12.46.15 pm.png

Basically—every time a user creates a new rule, we're going to clone it, link the issues together, and redirect the user via a comment (which should also be sent to their email). You can change these components to be whatever you'd like. For example, you might want to run this manually instead of on every new issue, and you want to update the description instead, in which case you'd change the trigger to a 'Manual trigger' and run an 'Edit issue' action. Automation is flexible enough to handle pretty much whatever you throw at it.

In your 'Create Issue' action, we're going to set it up a little bit like this:

Screen Shot 2017-12-18 at 12.46.20 pm.png

Except for a couple of things:

  • Set 'Project' to B
  • Change the summary and description fields as you want
  • Choose some fields to set, and set them like you want. If you want to copy the field from the original, enter {{issue.fields.<field name>}} like I've done above.

Those {{expressions}} are called Smart Values, and we use them a lot in Automation. They're a really easy way to access values of fields so you can use them elsewhere. Here, 'issue' refers to the issue that the customer created in 'B', and from there we can access the issue's 'fields', like 'description' and 'summary'. For each one, we need to surround it in the curly brackets. More on Smart Values here.

For the other actions:

Screen Shot 2017-12-18 at 12.46.28 pm.pngScreen Shot 2017-12-18 at 12.46.32 pm.pngWhenever you're trying to run actions on a new issue, you should reference 'Most recently created issue', which will grab the one you just made. When using smart values, you'll want to reference {{createdIssue}} instead of {{issue}}.

Let me know if there are any problems with this setup, and if you need any help with Automation don't hesitate to contact support.

Huw

Intern Developer at Code Barrel

Thomas Balasch December 21, 2017

Hey Huw,

thanks for your detailed answer. Cloning fields or issues wasn't really the issue for me, I was able to achieve that in 'Automation' and also via 'Misc Custom fields'.

But I never really was sure, if "most recently created issue" was a safe way of targeting a ticket (given the case, two users create tickets at (alsmost) the same time). Also adding a comment with a reference in a comment might come in very handy.

The one big problem I still can't solve so far is, how to make that ticket editable for the costumer in the Service Desk Portal, so I can set some fields (via cloning) before and let them fill in the rest, which would be mostly muliselect fields and a couple of Textboxes.

I tried 'Actions for Jira' in that regard, but the Addon currently has some major rendering flaws, which make it useless at the moment.

I guess there is no way to use 'Automation' in that scenario?

 

Best regards,

Thomas

Huw Evans
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 21, 2017

Hey Thomas,

We handle the state of the application such that 'Most recently created issue' will grab any issues created during the process. It's labelled as such because a user might not have created an issue in the rule by the time 'Most recently created issue' is hit—in which case we fall back on whatever was most recently created. It's all good.

You should be able to use 'Create Service Desk Request' instead of 'Create Issue', and copy over the 'Raise on Behalf Of' field with the issue reporter. I haven't been able to test it because this action is currently broken on our end, but we'll have a fix later today and I'll let you know when that's done.

Cheers

Huw

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events