Based on parent ticket transitioning status, show or hide options in subtask tickets

VVC
Contributor
June 6, 2024

We have a unique requirement to display or hide options under a drop down custom field in all subtasks on both create or edit screens based on the parent issue type ticket status. Any leads on how to achieve this solution would be greatly helpful for us using Adaptavist behaviors or other possible alternate solutions?

For example:

This should cover two scenarios.

#1 - When a parent change ticket status is in any status other than APPROVED, then the custom drop down "Deployment Environment" field in the change subtask ticket should display only "DEV", "UAT" for selection on both CREATE and EDIT screens.

#2 - When a parent change ticket status is set to APPROVED, then the custom drop down "Deployment Environment" field in the change subtask ticket should display "DEV", "UAT" and "PROD" for selection on both CREATE and EDIT screens.

1 answer

1 accepted

0 votes
Answer accepted
Stefan Stadler
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.
June 10, 2024

Hi VVC,

you are basically asking for two different questions:

1. How can I get the status of the parent issue?

2. How can I hide an option in a dropdown list?

The answer to your second question seems to be covered here already: Solved: hide options from select list field values based ... (atlassian.com)

Regarding your first question, this seems to be fairly simple:

issue.getParentObject().status.name

You may combine this like that in an initializer for your subtask issue:

if(issue.getParentObject().status.name == "APPROVED"){
//show the prod option
}
else{
//hide the prod option
}

 Hope this helps :)

Regards, Stefan

VVC
Contributor
June 10, 2024

Thanks @Stefan Stadler for this reference. I will give this a try and see how it works for me.

VVC
Contributor
June 12, 2024

I found another source reference, where this below script that was added under behaviors - Initialiser seems working only for EDIT but not for CREATE subtask action.

Any suggestions on how to get this working on the creation of subtask as well?

 

import com.atlassian.jira.component.ComponentAccessor

def issue = underlyingIssue

def customFieldManager = ComponentAccessor.getCustomFieldManager()

def customFieldId = "customfield_xxxx" // The custom field in the subtask

def customField = customFieldManager.getCustomFieldObject(customFieldId)

def formField = getFieldById(customFieldId)

if (issue.isSubTask()) {

    def parentIssue = issue.getParentObject()

    if (parentIssue.getStatus().getName().equals("Approved")) {

        // Show options

        formField.setFieldOptions(["QA", "UAT", "PROD"])

    } else {

        // Hide options

        formField.setFieldOptions(["QA", "UAT"])

            }

        }

 

 

Stefan Stadler
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.
June 12, 2024

Hi VVC,

I am pretty sure that behaviours also work in sub task create actions. In fact, I have just tried out a simple example:

getFieldByName('Business criticality').setFieldOptions(['normal'])
There is another value existing usually, but this was not available after this.
Additionally, it is needed to use the issueContext as the issue you are about to create does not actually exist in the create screen. That is why underlyingIssue is not initialized.
And therefore, getting the parent has to be done by the "field" parentIssueId.
So based on what I tested quickly, this should be your solution:
import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.issue.IssueManager

import com.atlassian.jira.issue.Issue

//only run if the issue to be created is a Sub-task

if(getIssueContext().getIssueType().name=="Sub-task"){

    //get parent issue

    def parent = getFieldById("parentIssueId")

    Long parentIssueId = parent.getFormValue() as Long

    IssueManager issueManager = ComponentAccessor.getIssueManager()

    Issue parentIssue = issueManager.getIssueObject(parentIssueId)

//this sets the parent issue from the underlyingIssue if it is not set
//this handles Edit screens

if(!parentIssue){

parentIssue = underlingIssue?.getParentObject()

}

    //get field to change

    def field = getFieldByName('your field name here')

    //change values based on status name

    if(parentIssue.status.name == "Approved"){

        field.setFieldOptions(["QA", "UAT", "PROD"])

    }

    else{

        field.setFieldOptions(["QA", "UAT"])

    }

}
Let me know, if this helped solving the issue :)
Stefan
Like VVC likes this
VVC
Contributor
June 14, 2024

Thanks @Stefan Stadler for your time. Your code is working as expected but I'm seeing one issue. When the Parent ticket status is other than APPROVED and if we EDIT an existing subtask then the PROD option becomes visible and selectable in the dropdown, which seems to be incorrect. Any thoughts?

Also, note that the PROD option is NOT listed now when creating a new sub-task.

 

 

Stefan Stadler
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.
June 15, 2024

Hi @VVC ,

PROD will only be available, if this is in the overall list of options in the custom field configuration. So only configured options can be chosen to be available here.

Regarding the EDIT, you can add some further "if" in your code. The code could be look like this:

if (getActionName() == null || !(getActionName() in ["Create Issue", "Create"])) {
return
}

import com.atlassian.jira.component.ComponentAccessor

import com.atlassian.jira.issue.IssueManager

import com.atlassian.jira.issue.Issue

//only run if the issue to be created is a Sub-task

if(getIssueContext().getIssueType().name=="Sub-task"){
if (getActionName() == null || !(getActionName() in ["Create Issue", "Create"])) {
return
}

    //get parent issue

    def parent = getFieldById("parentIssueId")

    Long parentIssueId = parent.getFormValue() as Long

    IssueManager issueManager = ComponentAccessor.getIssueManager()

    Issue parentIssue = issueManager.getIssueObject(parentIssueId)

    //get field to change

    def field = getFieldByName('your field name here')

    //change values based on status name

    if(parentIssue.status.name == "Approved"){

        field.setFieldOptions(["QA", "UAT", "PROD"])

    }

    else{

        field.setFieldOptions(["QA", "UAT"])

    }

}

 The above script would now only execute in case you are creating an issue. On Edit it will not work, which means all the field options would be available.

See here for more information on how to limit the behaviour to a certain action:

https://community.atlassian.com/t5/Jira-questions/Limiting-Behaviour-Script-to-Create-Issue-Action/qaq-p/1287621

If you want to ensure that the state of the issue creation is kept, you will have to store some invisible custom field in the sub task to remember the decision on issue creation.

From the description you provided, I am unsure, how the behaviour should behave, but with the examples above, I believe you can modify them to what is needed :)

Regards, Stefan

VVC
Contributor
June 18, 2024

Hi @Stefan Stadler -Apologies if the requirements were not clear before. The subtask should not show a PROD option during the CREATE and EDIT phases unless the status of the parent ticket is APPROVED. The PROD option should only be available in the subtask for both CREATE and EDIT modes when the parent ticket's status is APPROVED.

Is this still feasible with behaviors covering both CREATE and EDIT modes?

Stefan Stadler
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.
June 19, 2024

Hi @VVC 

in this case, the first suggestion seems to be correct. It simply was not working as the parentIssue is null for Edit screens.

I have just updated it accordingly as the parentIssueId field is only available in create screens. In Edit screens, the issue is already existing, which is why underlyingIssue can be used as a fallback.

Please check if the updated post is now working.

Thanks!

Like VVC likes this
VVC
Contributor
June 24, 2024

Thanks @Stefan Stadler for your assistance. The revised script worked exactly to our requirements.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
VERSION
9.12.6
TAGS
AUG Leaders

Atlassian Community Events