Restrict options in a single-select list based on Issuetype

[Will]

I received the following request form a user. The requirement is to have a single select list, most of which can only be selected if the issue is a sub-task, some values have additional requirements. Exact request pasted below:

If necessary, we would remove the Found In field from the Edit screen so that the rule couldn't be circumvented by simply editing the issue. We have a semi-solution in place but I was thinking that the toolkit could possibly handle this better.

[Fidel Castro Armario]

Options for a Select List can be made dependent on issue type (and hence on being a sub-task) and/or project using contexts. This is a native feature of JIRA, and you don't need any add-on to do it.

What you can't do without a plugin is to make valid options dependent on parent's issue status.

JIRA Workflow Toolbox can provide a validator for checking in a transition that the value selected in field "Found In" satisfies desired conditions. I will explain you how to configure a validation for all your requirements:

Use "Boolean validator with math, date-time or text-string terms" with the following configuration:

Boolean expression used is:

(%{14400} in ["Unit Test", "System Test", "UAT", "Early Production"] IMPLIES %{00041} != null) AND (%{14400} = "Early Production" IMPLIES %{00042} = "Released") AND (%{14400} = "Production" IMPLIES %{00041} = null)

Notice that:

• %{14400} is field code for "Found In" custom field. This code depends on each particular JIRA instance
• %{00041} is field code for "Parent's issue key".
• %{00042} is field code for "Parent's issue status".

[Will]

The above is helpful. I'm using post-functions to get us mostly there now. We have hundreds of Jira projects, most with custom contexts and fields and making changes to projects can get pretty hairy. I was thinking that just as you run validation on the selection based on parents' status that we could just add some similar checking to not allow the Unit Test, System Test and UAT options selectable on non-subtasks.

Regardless, your solution is perfect for adding logic based on parent's status.

Thanks!

UPDATE: mistaken, not using contexts for this. See next reply.

[Will]

I'm getting an error when trying to create a new issue when the issuetype uses a screen that the Found In field is not present on. How do I exclude this validation check on "Change" issuetypes OR better yet all issuetypes that != Bug or Subtask?

EDIT: the error is "Error creating issue: An unknown exception occured executing Validator com.fca.jira.plugins.workflowToolbox.MathExpressionsValidator@51028678: root cause: java.lang.NullPointerException" which I am just assuming is presented due to the Found In field not being used on this issuetype.

Thanks

[Fidel Castro Armario]

Will, can you please show me the part of the server's log file with the NullPointerException's stack-trace. It will be very useful to find exactly the cause of the error.

[Fidel Castro Armario]

Use the following boolean expression:

%{00014} not in ["Bug", "Subtask"] OR ((%{14400} in ["Unit Test", "System Test", "UAT", "Early Production"] IMPLIES %{00041} != null) AND (%{14400} = "Early Production" IMPLIES %{00042} = "Released") AND (%{14400} = "Production" IMPLIES %{00041} = null))

I'm assuming that "Bug" and "Subtask" are exact names of two issue types in your JIRA instance.

[Will]

Doesn't seem to be reflected in the logs at all...

[Fidel Castro Armario]

It should have been registered, since all exceptions are. Usually in "catalina.out" log file. You can try forcing the error and looking immediately.

[Will]

There may be something. I'm forwarding the log to your email directly.

I changed the expression to the new one you provided and I get the same error.

[Fidel Castro Armario]

Thanks. Anyway, the alternative boolean expression I provided you should solve the problem.

[Will]

Disregard. Think it’s fixed.

Needed to expose the Found In field to the issue type 'Change' via contexts even though it’s on no screens associated with 'Change' type issues. I assume it just has to be there so that the validation can check it.

[Fidel Castro Armario]

Anyway, the error message shown to the user should be something more informative. I will fix it in the next version of the plugin.