Custom field - how to use a subset of choices in one issue type, other subset in other issue type

[Amir Katz (Outseer)]

I have a single-choice custom field with values A1, A2, B1, B2.

In the project I have two issue types, A and B.

The field is associated with both issue types.

When I'm creating issue type A, I want to see only the A1 and A2 as the choices.

Similarly, for issue type B, B1 and B2 only.

I went by the book and created two contexts in the custom fields.

• Context A is for issue type A and has options A1 and A2;
• Context B is for issue type B and has options B1 and B2.

I defined context A to apply to my project only.

Now in the context B, I cannot associate it with my project, so it becomes global (=all projects).

When creating issue of type A, I indeed see only options A1 and A2.

But when I try to create an issue of type B, I do not see the field. When I look for it, I get the error below. It seems that the project scope of context A won, as they say in the custom field config page:

You can configure a custom field differently for each project context or in a global context. Moreover, project level schemes will over-ride global ones.

I wonder if this is exactly the case in here: https://jira.atlassian.com/browse/JRASERVER-6851

Anyone has an idea? I can probably use ScriptRunner Behaviour to dynamically modify the choices based on the issue type, but that's a really ugly hack.

[jesusoros]

Hi Amir,

Basically, the Custom Fields Contexts work based on Projects. Once you assign a Context to a Project you cannot add another one even when you use different Issue Types on the configuration of the Context.

I would reccomend you to use a cascading custom field and allow the users to select A or B on the first option and then A1, A2, B1 or B2 depending on the scenario.

Another option is for you to create 2 different Custom Fields for the A options and the B options.

Let me know if this helps or if I'm missing some important information that might allow us sme other options.

Thanks!

[Amir Katz (Outseer)]

Jesus,

Thanks a lot for your suggestions. Both are great for a new project.

However, this is an existing project with ~800 issues in it.

I did consider the cascading fiedd and rejected is because I have a lot of scripting code based on this field, so it would require rewrite of several groovy scripts (validators and behaviors).

Another problem would be that now the values of the cascaded field would be A-A1, A-A2, B-B1, B-B2, and thus many filters and queries will have to be rewritten (since they check on the current values A1, A2, B1 and B2).

The other option (2 fields) is not good either as existing filters and scripts are relying on that single field. I can hack around it and create two fields (FA and FB) and add scripting to copy the values of either FA or FB to the old field (which will be kind of read-only), but again, that's an ugly hack.

I will check if I can dynamically change the selection options using ScriptRunner. I will report back my findings.