Listener Clone ticket is not updating a CF after creation

[Ronen Erlich]

Hi,

I am trying to use lister to clone a ticket when the original ticket is resolved and update the ticket cloned ticket with CF x to CF Y

My current settings are:

condition: 

cfValues['Request Type']?.value == 'X'

Additional issue actions:

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.issue.Issue

import com.atlassian.jira.issue.ModifiedValue

 

def cf = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Request Type")

issue.setCustomFieldValue(cf,'Y')

issue.setAssignee(null)

I also tried: 

def cf = customFieldManager.getCustomFieldObjects(issue).find {it.name == 'Request Type'}
issue.setCustomFieldValue(cf,'Y')
issue.setAssignee(null)

so the ticket is cloned and the relevant fields are copied but the request type is X and not being modified to Y. It is not even showing up on the cloned ticket so I believe the value is being 'null'...
any idea what I am doing wrong?
thanks,

[Rachel Wright · Accepted solution]

Hi Fred, no need to worry about new admin questions.  We were all new once and we all had this same question, believe me!

You can do this with a workflow validator.  I believe these days this function comes with JIRA and doesn't require installing a specific plugin.  (I just checked a Cloud instance with no plugins and it's there.)

Implementation

1. Open your workflow for editing
2. Click on one of your transitions
3. Click on the "Validators" tab 
4. Click the "Add Validator" link on the right (see screenshot)
5. Add for the validator called "Field Required Validator" and choose the specific field make required

Tips:

Validators are checked and must return true before the transition completes.

Unlike requiring a field on a create screen, no asterisk (*) symbol will display for a field required by a workflow.  The end user will receive an error message however, if the field is not completed.

As you mentioned, it's a good idea to add a transition screen (not pictured) to allow the user the oportunity to set or update the required field.  Otherwise, if the filed has no value, the user will get a workflow error.

Now, if you want to do something fancy that's where Scriptrunner for JIRA comes in!  Here's a link to their documentation on workflow functions:  https://scriptrunner.adaptavist.com/latest/jira/custom-workflow-functions.html

Hope this helps!

Rachel Wright

[Fred Gruhn]

Rachel,

Thanks again for such a quick reply. I tried to apply this on my hosted JIRA instace (7.3.0) and on my Add Validator screen, I don't see a "Field Required Validator" in the list. I only see the following (see screenshot below). Does it make a difference that I'm adding the validator on an "All" transition for a state?

[Micha]

Does anyone still have an answer to Fred's last question? I am facing the same problem.

[Thorsten Letschert _Decadis AG_]

Hi @Micha,

whether you're dealing with an 'All' transition or not does not make a difference here. While a 'Field required' validator is available on Jira Cloud by default, Jira Server relies on 3rd party apps in order to provide such a functionality.

Cheers,
Thorsten

[jbeg]

Just found this answer... Is this true? Jira Server is not able to perform this simple and basic task that we have to rely on a 3rd party developer and a PAID plugin?

Im getting this right, Jira Server is not able to make a transition validator based on its own fields, yes?

[jira beginner]

That's right. Jira server does not have filed required validator pre-install. 

[Bob_Radu]

That is ridiculous as a missing feature.

[Apoorva Srinivas K]

Hello Team, 

I cannot see the "Validators" tab in the company-managed project. Where can I enable this option? I need to make it mandatory to enter a customer field before we move from one stage to another 

[Maciej Dudziak _Forgappify_]

Hi @Apoorva Srinivas K 

You are seeing the new workflow editor, there is an option to switch to the old editor

Cheers

[Ryan Willms]

Is the option to switch to the old workflow editor only available for Service Projects? (https://support.atlassian.com/jira-service-management-cloud/docs/changing-your-default-workflow-editor/). 

I am trying on a Software Project and do not see a More (...) option.

[Maciej Dudziak _Forgappify_]

No, but maybe you are in a team-managed project? In team-managed projects there is only this new editor. You can switch to the old editor in company-managed projects.

[JamieA]

I suspect the reason why Rachel found it in the cloud instance is because "Suite Utilities for JIRA" is pre-installed...

You can do this with ScriptRunner easily using a Simple Scripted Validator, but if you don't need any conditional or programmatic logic, you may as well use SUJ which is a free plugin AFAIK. 

You mention you have this on the All transition, but it would be simpler to put it on the specific transition you care about, then use Fields Required Validator.

[Tommy Lu]

It's no longer free as of Jul 13, 2017.
https://community.atlassian.com/t5/Marketplace-Apps-Integrations/Suite-Utilities-for-JIRA-JSU-app-is-now-commercial/td-p/609117 

[Somesh Sahoo]

Jira Field MANDATORY While Closing the Issue
https://youtu.be/W3vhZJkJ52A

[Somesh Sahoo]

https://youtu.be/W3vhZJkJ52A?si=T43oxxSTgXiqL26p

this is the easiest way to make the field mandatory for a transition without.

[Code to live blog]

I can explain how to make a custom field required during workflow transition. You can refer the detailed steps on my below blog post,

https://codetolive.in/jira/How-to-make-custom-fields-required-in-a-workflow-transition-in-jira-script-runner

[Jonatan Rueda]

Is there any way to apply this validation only for a specific Issue Types?

[Piotr Janik]

Not sure about Adaptivist stuff, but in Jira itself different issue types can use different workflows. You can e.g. couple IssueTypeX with WorkflowX, then make a copy of WorkflowX (hereinafter WorkflowXa), add the validator to WorkflowXa (but not to WorkflowX), then couple IssueTypeY with WorkflowXa. The downside is that you'll need to update both workflows separately even if the validator is the only intended difference...