Conditional Fields when Editing Issues in Jira

[Gian Israel Nampi]

Hi Atlassian Community!

I have a task to create mandatory fields base on the conditions.

When a user specified a value in select list (single choice) "custom_field_1"  it will trigger the "validators" which is if it meets the value set in the "custom_field_1" then the user will need to specified a value in "custom_field_2"which I have set in the workflow transition. This is already done.

The problem is when the user edited the issue it allows transition moving into the next transition even if it the user specified or did not specified any values. making my "validators" unusable or bypass the conditional mandatory fields I have set as a requirements.

The client did not agree with my workaround to hide the "custom_field_1" and "custom_field_2" in the "Edit issue screen" so it gives me the option to replicate my settings from the workflow to the edit issue screen.

Do you have any recommendation on how to make conditional mandatory fields when the issue is being Edit? if it requires a script can you give me an example please?

Version: Atlassian Jira (v8.5.4)

Thank you.

[Gian Israel Nampi · Accepted solution]

Hello Everyone,

For those who are facing or have similar issues with me I have raise a support ticket to Adaptavist, and they are very responsive and helpful with my request.

My Requirements:

Have a conditional mandatory fields: when a value is use in "Custom_Field_1" then "Custom_Field_2" and "Custom_Field_3" will be mandatory.

What I did?

Added "Validators" in the Workflow Transition.

What is missing?

When the user try to "Edit" the issue the "Validators" that I set is not working therefore the user can easily bypass the restricted fields. which is not also good for "Auditing" purposes.

Solution:

Use "Behavior" Add the "Custom Field" that requires the condition, and add server side script and mapped it to the corresponding Project and Issue Types.

Links:

Using Behaviors

Adaptavist Library 

Code:

def customField1IssueField = getFieldById(getFieldChanged())
def customField2 = getFieldByName("cfname2")
def customField3 = getFieldByName("cfname3)
def customField4 = getFieldByName("cfname4")


String customField1IssueValue = customField1IssueField.getValue()

switch(customField1IssueValue){
    case 'Value1':
 case 'Value2':
 case 'Value3':
     customfield2.setRequired(true)
     customfield3.setRequired(true)
     customField4.setRequired(false)
     break;
    case 'Pre Committed':
     customfield2.setRequired(true)
     customfield3.setRequired(false)
     customField4.setRequired(true)
     break;
    default:
        customfield2.setRequired(false)
     customfield3.setRequired(false)
     customField4.setRequired(false)
        break;
}

I would like to thank Bobby Bailey, of Adaptavist, for helping me solved this problem. Salute!

[andrewd]

Hi @Gian Israel Nampi 

I am Andrew, Support Engineer for ThinkTilt, vendors of the ProForma app.

A solution for your business use case would be to utilise the ProForma product. We have a free version (ProForma Lite) which you could use to test it out for this scenario (ProForma Lite allows creating up to 3 form templates)

The ProForma product
- supports the question types you're mentioning here
- allows associating forms to issue types (or request types)
- allows linking to custom Jira fields
- is usable across the different Jira platforms (Cloud, Server, D/C) and products (Software, Service Desk)
- allows questions to be set to mandatory to force data entry from the user
- supports use of conditional sections, which are sections of questions (one or more) which are displayed to the user based on the value of a previous question in the form.

Info on using conditional sections is available at the following link: http://links.thinktilt.net/am-dynamic-fields

More information on ProForma and what it can do is available at the following links:

https://marketplace.atlassian.com/apps/1215833/proforma-forms-checklist-for-jira?hosting=cloud&tab=overview

https://docs.thinktilt.com/

Does this info make sense and of any help?

Let us know what you decide to do.

Regards,

Andrew.

[Nic Brough -Adaptavist-]

You will need an app like Behaviours to do this in the front end.  You can't do it in the back-end at all, so REST users will always be able to bypass such validation.

[Gian Israel Nampi]

Hi @Nic Brough -Adaptavist-

Thank you, I am trying the Adaptavist Script Runner "Behavior" and tried to copy a sample script base on other threads here. if the commitment value is "Committed" then the "Due Date" system field must be set to mandatory. I tried to edit the issue and use the Committed value but it allows me to edit the issue without making the Due Date warning as mandatory field.

if (getActionName() == "Edit") {

    def commitmentIssueField = getFieldById(getFieldChanged())
    def dueDateVersionField = getFieldByName("Due Date")

    String commitmentIssueValue = commitmentIssueField.getValue()

    if (commitmentIssueValue == "Committed") {
        dueDateVersionField.setRequired(true)
    } else {
        dueDateVersionField.setRequired(false)
    }
}

Do you have any idea please?

Thank you so much.

[Gian Israel Nampi]

I tried another version of the script and still when editing issue (At the Edit Issue Screen), setting the "Commitment" field into "Committed" value does not make the "Due Date" field mandatory.

if (getActionName() == "Edit") {

    def commitmentField = getFieldByName("Commitment")
    def dueDate = getFieldByName("Due Date")

    def commitment = commitmentField.getValue()

    if (commitment == "Committed") {
        dueDate.setRequired(true)
        dueDate.setHidden(false)
    } else {
        dueDate.setRequired(false)
        dueDate.setHidden(true)
    }
} 

The Script Runner is up to date to the latest version and is enabled.

Can someone help me please?

Thank you.