Adding custom field values in an automation rule

[Aaron Blacklock]

Hi all,

When creating a Service Desk ticket via the portal, I'd like our customers to not enter the title in the summary and select the item they require from a dropdown list.

To that end, I've created a custom field with the drop down elements, and hidden the value of the summary. I'd like the summary to change its value to that of the dropdown list. 

Is there a particular JQL script I need to use here? 

[Julie d_Antin _Elements_]

Hi, the summary field is a required field since it's the title of the issue, and if you hide it you won't be able to create any issues. It's one of the hard rules of Jira.

Perhaps making the component field required on your issue creation screen would help since you can configure the values of the component field and it works as a dropdown list.

JQL is a search language, not an automation/scripting language, so you can't update issues using JQL in the way you want to.

By the way, are the choices you would like to have in the custom field drop down from external sources? Like a product database or list of locations managed outside of Jira?

[Aaron Blacklock]

Hi there,

I should have clarified, I've hidden the value of the summary as it is still required, but I'm looking to use an automation rule to change the value of the summary. 

For example:

X raises a ticket that they require a new phone. they use a "request new hardware" issue type where the summary field is hidden. They are presented with a custom field called "hardware" which is a multiline choice custom field wherein they select "phone", they complete the rest of the ticket and submit it.

In this instance, I'd like the automation to find the value of "Hardware" and replace the value of "Summary" so that my customers are not having to put in the same detail twice. The custom field is created within Jira itself and added to the screen scheme so there's no issues about it being external (apologies if I misunderstood that part) 

[Julie d_Antin _Elements_]

Pretty sure no one will be able to create an issue (the button will not be available) if the summary field is empty (the case if the field is hidden).

You could try updating the summary field after the issue creation, but it can't be empty on issue creation.

[Aaron Blacklock]

Its not that the value is empty, its filled with a predetermined value as part of hiding the field. 

During the automation creation process, I can choose to then replace the predetermined value based on the issue meeting the criteria. I've tested and proven that this is possible however I cannot find the correct way of making the automation use the value selected in the custom field to fill the value of the summary, 

[Pierre Sauveur]

As far as I understand, Automation will not help for that (at least not directly), as the rules are launched only after the detection of an event (create that is for your exmple)

In a JSM Cloud, here is how I would do:

1. hide the summary from the request form, and set a generic value in it (ex: "request new hardware")(NB: was it possible in 2019?)
   and make the "Hardware" field available and mandatory
2. the copy to summary part will be tricky though, with a Jira out of the box:
   1. either you use a workflow post function to copy the "Hardware" value in the summary, but you will only be able to copy the value of the "Hardware" field in the summary, not replace one word of the summary as I think you want to
   2. or use an automation rule: you may be able to have a better conrol of the value you set in Summary, but the update will be executed only after the Create event, so the first email notification will be sent with the Summary before update

PS: Late answer, as I crossed this topic by chance only now. I felt this could still help a bit other users

[Rabbit Stoddard]

I have successfully done this by hiding the summary field with the value: 

Request new $hardware for $user

Then I have an automation that triggers on create that changes the summary to Request new Phone for Jane Doe. 

To solve the notification issue, I would disable customer notifications on create, or modify the customer facing notification to say something else, and trigger notifs on update, or have an email also be an action for the rule.  The problem here is that this would apply to the whole project, not just the request type in question, so you'd have to do custom notifications for all request types, which might be a big pain.