Can a custom field select list have different options based on the issue type/screen it is used for?

[Justin Corcoran]

I have a custom field called "System" which lists all systems that may be impacted/relevant. Different issue types have different relevant systems (e.g. a "support issue" could be about basically any system, but a "data pull" would only come from one of a select few systems).

can i limit/alter the system options avialable based on the issue type or screen that the custom field exists on? this question sounds like it might be related to what i'm asking for (rerfers to custom field contexts, but i'm not sure if you can have multiple contexts based on issue type for the same project) https://answers.atlassian.com/questions/41092/same-name-custom-field-makes-me-confused-when-trying-to-add-same-name-field-to-screen

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

You can have different options for a custom field based on project or issue type. Not based on screens. Create different contexts for different options as described here: http://confluence.atlassian.com/display/JIRA/Configuring+a+Custom+Field#ConfiguringaCustomField-Context

[Jobin Kuruvilla [Adaptavist]]

Yes, that's right. It won't work if you try to do it per issuetype per project. Did you instead try per issuetype and for all projects (global)? Does it work for you?

[Justin Corcoran]

Based on what I see when I try to configure contexts, it appears that I can only have 1 context for a custom field per project. Is that correct? I modified the default context for my "system" custom field, and applied it to issue type "Support Issue" and project "Support Issues". When I add a new context, I can choose issue type "Data Extract" but I can't choose project "Support Issues". That option isn't even in the list.

[Justin Corcoran]

That doesn't really work either. The second context forces me to choose a project. Therefore, if I have 3 issue types for the same project (which I do) and I need different values available for each issue type, I can't seem to configure this. Context 1 is global for issue type 1, context 2 is project specific for issue type 2, and I can't tie context 3 to the specific project, or make it global.

[Jobin Kuruvilla [Adaptavist]]

I see. Sorry that didn't help. I am not sure why it doesn't work though. Maybe for Atlassian to look at it!

[Justin Corcoran]

No worries. thanks for the suggestion. I've asked Atlassian to weigh in.

[Justin Corcoran]

Yeah, it's starting to look like that's my only option. I was hoping to avoid that, simply to make configuration less of a headache, but if that's what I have to do, so be it.

[Jobin Kuruvilla [Adaptavist]]

Cool. The only otehr option I can think of is to use same name for different fields. Barring the confusion for admins, that will work fine for users. Another option is Javascript hacks.

[Toni Mofardin]

Has anybody came up with any solution? I have the same problem (in my case there are 4 issue types).

[Shay Murphy]

I have the same issue as described above, I need to be able to have a configuration for 3 issue types in the same project. I would prefer not to have to use the different fields as the value should be searchable across the 3 issue types.

Can you please provide more information about a Javascript solution, I would think the project should not be removed from the list if the issue type is different.

[Ezra Andhika]

I have the same issues here. Anybody has solutions for this?

[Karen Rodriguez]

Wondering if using "select list (Cascading)" custom field  would allow you to select first he issue type (Service or Data) and based on that, a second list is displayed with specific options for each.

[Nic Brough -Adaptavist-]

That won't solve anything.  It will provide a cascading select that offers Service or Data (and then the same sub-lists) on all issue types.

Jobin's solutions are still the only useful ones.

[Amit Girme]

Hi,

It could be late but may help others who are still looking for the solution

In behaviour add a mapping for the required project(s) and required issuetype(s)

go to the fields in that newly created mapping

add the required field whose value to be limited for this mapping from 'Add Field'

Click on the 'Add server-side script' and put your code there

import com.atlassian.jira.component.ComponentAccessor;

import com.onresolve.jira.groovy.user.FieldBehaviours;
import groovy.transform.BaseScript;
@BaseScript FieldBehaviours fieldBehaviours;

def customFieldManager = ComponentAccessor.getCustomFieldManager();
def optionsManager = ComponentAccessor.getOptionsManager();

def customfield = customFieldManager.getCustomFieldObject("customfield_1xxx5");
def customfield_config = customfield.getRelevantConfig(getIssueContext());
def customfield_options = optionsManager.getOptions(customfield_config);
def customfield_optionA = customfield_options.getOptionById(1xxx1).getValue();
def customfield_optionB = customfield_options.getOptionById(1xxx2).getValue();

def customfield_optionC = customfield_options.getOptionById(1xxx3).getValue();

def formfield = getFieldById("customfield_1xxx5"); // same customfield as above

formfield.setFieldOptions(customfield_options.findAll{it.value in [customfield_optionA,customfield_optionB});

This is a working solution for select list field. You can adapt the script for other field types

Hope it will help someone

Thanks,

-Amit

[desarrollo]

Thank you!! it works

[Cindy Mejia]

Another way to have a field default to a specific value is within the workflow. Go to the transition and add a Post Function > Update Issue Custom Field (and type in your default value). This method will be issue type agnostic and can be shared across multiple projects, so long as they share the same workflow. Enjoy!

[NCATS LAB]

This has been re-opened in the following tickets:

https://jira.atlassian.com/browse/JRASERVER-66849

https://jira.atlassian.com/browse/JRASERVER-67152

[Carol Jones]

I'm using the Behaviours functionality of the Script Runner plugin for this (paid plugin).  Not ideal as this should be a built-in function, but it works for us since we needed the plugin for other tasks anyway.

[rbarenka]

How you achieved multiple context per project using script runner plugin. Can you share your thoughts.

[Tennille Noach]

Can anyone update me on how they have managed to achieve this multiple contexts per project?  I have several issue types within a project that all need to display different options in the one Custom Field.  I would love to know how anyone has achieved this?

thanks!

[Nic Brough -Adaptavist-]

Log in as an admin, go to the list of custom fields and find your field, then click configure.  You'll be able to add many contexts, one for each issue type.

There is a problem with it, which is what this question is about - you can only do one set of contexts, based on issue or project

[Tennille Noach]

Thanks Nic, yes that is indeed the question. So is there a way to work around that problem of only being allowed to do one set of contexts per Project?  I have 5 issue types within one project and all need to display different values in the Custom Field multi select list, depending on the issue type selected.

[Carol Jones]

If you have ScriptRunner, you can do it through the behaviour functionality.  Below is the script you would need.

import com.atlassian.jira.component.ComponentAccessor
 
def customFieldManager = ComponentAccessor.getCustomFieldManager()
def optionsManager = ComponentAccessor.getOptionsManager()
 
def formField = getFieldByName("FIELD_NAME") // update FIELD_NAME with your custom field name
def customField = customFieldManager.getCustomFieldObject(formField.getFieldId())
def config = customField.getRelevantConfig(getIssueContext())
def options = optionsManager.getOptions(config)
 
// update below OPTION_ONE, OPTION_TWO, OPTION_THREE with desired options
// note the options listed need to first be configured within the full project field context and must match exactly

def optionsMap = options.findAll {
 it.value in ["OPTION_ONE", "OPTION_TWO", "OPTION_THREE"]
}.collectEntries {
 [
 (it.optionId.toString()) : it.value
 ]
}
 
formField.setFieldOptions(optionsMap)

[Tennille Noach]

Thanks so much Carol, I'm looking forward to testing this out when I get a spare few minutes today.  Stay tuned! :)

[Tennille Noach]

mm, not sure what's going wrong here for me, I think I have missed a step somewhere.  

The field was created and it has a Global context which includes all the issue types within the relevant Project, and lists all of the 28 Options that I want to be possible at various times.

Then in admin

- I created a new Behaviour

- I entered the script in the 'Initialiser Function' Validation Script section, as per screenshot, with the name of the custom field and the three desired options entered in.

 

- Then I used the 'Add Mapping' button to select the specific issue type that I wanted this particular behaviour to apply to.  i.e. the issue type that I want those set of three Options to be displayed on.  
? Was this the right next step?

- Then after adding the mapping, I tried to create a new Issue of that Issue Type, yet all of the different Options for that custom field still appeared on the screen, no matter which issue type I selected the Options for that custom field didn't change.

Not sure what I have missed?

[Amit Girme]

Hi,

It could be late but may help others who are still looking for the solution

In behaviour add a mapping for the required project(s) and required issuetype(s)

go to the fields in that newly created mapping

add the required field whose value to be limited for this mapping from 'Add Field'

Click on the 'Add server-side script' and put your code there

{code}

import com.atlassian.jira.component.ComponentAccessor;

import com.onresolve.jira.groovy.user.FieldBehaviours;
import groovy.transform.BaseScript;
@BaseScript FieldBehaviours fieldBehaviours;

def customFieldManager = ComponentAccessor.getCustomFieldManager();
def optionsManager = ComponentAccessor.getOptionsManager();

def customfield = customFieldManager.getCustomFieldObject("customfield_1xxx5");
def customfield_config = customfield.getRelevantConfig(getIssueContext());
def customfield_options = optionsManager.getOptions(customfield_config);
def customfield_optionA = customfield_options.getOptionById(1xxx1).getValue();
def customfield_optionB = customfield_options.getOptionById(1xxx2).getValue();

def customfield_optionC = customfield_options.getOptionById(1xxx3).getValue();

def formfield = getFieldById("customfield_1xxx5"); // same customfield as above

formfield.setFieldOptions(customfield_options.findAll{it.value in [customfield_optionA,customfield_optionB});

{code}

This is a working solution for select list field. You can adapt the script for other field types

Hope it will help someone

Thanks,

-Amit

[Krupasindhu Nayak]

Any solution to it? Even after couple of JIRA releases we face the same problem.

[Carol Jones]

I know this is an older conversation, but figured I'd add this in case anyone is searching for the same item (like myself): https://jira.atlassian.com/browse/JRA-6851

[MattS]

There is a remarkably detailed description of what custom field contexts can be used for, including issue types, at https://www.servicerocket.com/blog/2014/04/field-context-in-atlassian-jira/