Support smart values for Project field of Create Issue action

[Rick Westbrock]

Use Case

A service desk agent triggers a Jira Automation rule to create a related escalation issue in a different project by selecting a Tier 2/3 team from a user input prompt. The rule does a lookup by team name (either in a lookup table within the rule or an Assets lookup) to determine the appropriate project for the escalation issue.

The Create Issue action in the rule should create the escalation issue in the project it found in the lookup action.

Constraint

Currently the Project field of the Create Issue action only allows selecting a specific project from the drop-down menu and does not support smart values. This means we cannot dynamically select the project at runtime. 

Desired Behavior

The Project field should accept smart values in the same way that fields in the Edit Issue action accept them.

Workaround

As mentioned in this thread from five years ago the workaround is to use the Send Web Request action instead of the Create Issue action. This is an unsatisfactory solution because it will be beyond the capabilities of many project administrators and it more difficult to maintain as the API token must be updated every year when it expires.

[Rick Westbrock]

It turned out that my problem was using the project key so I changed the attribute from Text to Project to resolve that problem. I hadn't looked at the automation rule in a while but it is using `{{lookupObjects.prj.ID}}` where "prj" is the Project type attribute. The smart value doesn't "render" nicely like it normally does for other field types but the create issue action executes successfully.

[Rick Westbrock]

For the token field you can "hide" it which masks the value so anyone viewing the action later can't see the actual value in the field. That has the downside of making it impossible to validate what is in the field though. Thanks for the link, that is a clever design that I may try out when I get a chance.

[Rick Westbrock]

I just realized that for customers on JSM Premium you could create an Assets schema with restricted permissions and add an object type to store secrets. This would allow an automation rule to use a Lookup Objects action to retrieve the API token and store it in a variable to be used in a web request action.

Similarly you can create a "lookup table" in Assets for the list of project names, project keys and issue types instead of storing them in the automation rule, this is helpful when the number of projects gets very large as I find it's easier to maintain Assets objects than a lookup table in the automation rule.

[Maksim Beliaev]

see my comment below

https://community.atlassian.com/t5/Automation-discussions/Support-smart-values-for-Project-field-of-Create-Issue-action/m-p/2820492#M679

[Maksim Beliaev]

I ended up with an entirely different solution. Thanks to the newly added lookup functionality it is made possible

1. Ask use for the input where they would like issue to be created and the issue type

2. Create lookup table with Project Names (or whatever names you have in the user input) and the corresponding Jira project keys

3. Clone issue based on the IF condition

[Jan Stähle]

How can we specify the Issue Type in addition to the project Jira Automation within Jira Cloud? 

[Haddon Fisher]

Not sure if this question is still out there but if it helps, I actually found a solution I like better than the web request; I've mapped it out here.

The other issue I have with the web request is that the API token is stored in the rule as plaintext, which means anyone with access to editing the rule would be able to get at it. This is not a huge deal now that you can actually permission rules, but still I guess kind of a thing.

[František Špaček _MoroSystems_]

Well that "field" called "Project" in the automation action settings accepts project IDs. You can probably have text attribute in Assets but it needs to have ID in it and not the key. It's basically up to you how you get the ID - whether you link the project in assets and get ID from that project object or you have text/number attribute directly with ID in it. Both ways should work just fine.

[Rick Westbrock]

I have been working with a consultant on implementing JSM and he found that in the Assets lookup object type if we use a Project attribute instead of a Text attribute (holding the project key) that we can use a {{lookupObjects.Project.ID}} smart value in the Project field of the create issue action.

I had submitted this request initially because the Create Issue action was not working when I was using a Text attribute in the lookup object.

[Rick Westbrock]

Interesting, for my use case I would have to have the automation rule first set the value of the project key into an issue field (we don't have an appropriate field so I would have to create one) and then put a Re-fetch Data action then finally a Clone Issue action.

I had not even thought about using the Clone Issue action as I didn't necessarily want an exact clone and not having used this action before I wasn't aware that I could modify fields in the cloned issue so I'll give this a try.

[František Špaček _MoroSystems_]

I have just tested that with "Clone issue" functionality and it does accept smart value. It needs to be a project ID but it does work eventually.

My case is that we have Application catalogue in Assets and each application there has attribute called "Jira Project" (field type Project). User on the portal has to pick Application that his change/incident/request is connected to and if the L1/L2 is uncappable of solving that request a simple workflow status "Escalated to L3" will result in automation being run. This automation checks application selected in assets database and use "Clone issue" with this smart value: "{{issue.Application.Jira Project.id}}" used in Project field. You can use the same way for issue type or select directly whichever you want to have.

It does not utilize user input as you mentioned but the basics are the same (and I hope it works for Create issue too).

[Matt Rogers]

We also have this requirements — we have multiple team backlogs and want to use automation plus a user input value or lookup table to derive which project a Helpdesk issue should be escalated to. Not being able to use a smart value in the project and issue type fields during Create Issue action means we have to have 5+ copies of what is otherwise the same action, plus all the associated IF statements.

[Rick Westbrock]

I am using an Assets lookup to find the appropriate project where the Escalation Project attribute holds the project key. The automation rule sets this value into the {{esclatationProject}} smart value but when I use that smart value in the Project field of the Create Issue action I get back this error "Specify a valid project ID or key (project)".

Based on that it appears that smart values are in fact not supported.

[Rick Westbrock]

Thanks, I was aware of those but my concern is that if I type or paste a smart value in the Project field it does not render visually in the same way that it does for other fields. To be fair I didn't try saving the action and executing the rule so I will give that a try; I was put off by the different visual behavior in the UI but clearly should have tried testing end to end anyway.

[Curt Holley]

Try these on for size @Rick Westbrock 
Jira smart values - projects | Cloud automation Cloud | Atlassian Support

[Rick Westbrock]

If you replace "service desk agent" with "any user" and just want the ability to spawn a related issue in another project then this is a more general request for Jira Software. Not everyone who might want to do this will have a JSM subscription to access OpsGenie. (I will be implementing OpsGenie in the future but there's a lot to unrwap there which I won't have time for during our initial implementation).

More generally speaking since other fields allow the use of smart values even when a drop-down is available (user picker for example) I just don't see why the Project field should be any different.

[Curt Holley]

Wouldn't using Opsgenie be a slicker way to go about escalating to a resolver group/team?
Opsgenie could then in turn create an issue in the relevant Project.