Condition "Value Field" does not work

[Michael Voronkov]

Steps to reproduce:

1. Add the "Value Field" condition to the workflow transition from state A to state B:

2. Select the following options: Field: Resolution Condition: != Value: NONE

Reference on resolution field: "resolution": { "self": "https://jiratest.d3nw.com/rest/api/2/resolution/11", "id": "11", "description": "Resolution is not set", "name": "NONE" }

3. Publish workflow draft

4. Move an issue from state A to state B

5. On transition screen leave Resolution at its default - NONE

6. Complete transition successfully to state B

EXPECTED RESULT: The above condition should prevent transition to state B if Resolution = NONE

NOTE: None of the comparison types worked: String = NONE Number = 0 (made 0 as default Resolution) Option ID = 11

[Fidel Castro Armario]

Hi Michael,

None of the two conditions you are using belongs to JIRA Workflow Toolbox. Nevertheless, you can implement your requirements using conditions "Condition based on regular expression" and "Condition on subtasks".

I show you how to do it in the following screenshots:

1.- Condition based on regular expression:

2.- "Condition on subtasks":

Once configured, transition looks like this (in JIRA 6.2):

Please, close this issue if this solution solves the issue.

[Michael Voronkov]

Hi Fidel, thanks for the quick response! Still have the following issues: 1. Condition based on regular expression - Resolution doesn't show up on the drop-down list, but I can retrieve it through an API call. I use R key - so I cannot miss it.

2. Condition on subtasks - no luck, I still can move bug with open sub-tasks from one state to another (published workflow draft). see attached image

[Fidel Castro Armario]

Condition "Condition based on regular expression" should show field "Resolution". I'm afraid you missed to find it. Look at the screenshot and tell if you keep having problems to find it:

BTW, field Watchers in the screenshot is not yet available. It's a new field coming in version 2.1.16.

[Fidel Castro Armario]

If you want a behavior equivalent to your initial requirements, you should use the configuration I showed you in my first response.

Anyway, if you want to be more specific, and only set conditions for issue type Dev Sub-Task, you should uncheck parameter Allow unselected statuses, as shown in the screenshot:

[Michael Voronkov]

I see discrepancy between what's in Jira DB and what is returned by plug-in. 1. According to the plug-in, there's no such field as Resolution - see attached Workflow_Transition_Condition.png. However, it shows "Issue Resolution" field. 2. According to Jira (https://XXXXXX.com/rest/api/2/field) there's no such field as "Issue Resolution", but there's Resolution field: { "id": "resolution", "name": "Resolution", "custom": false, "orderable": true, "navigable": true, "searchable": true, "schema": { "type": "resolution", "system": "resolution" } See attached Jira_Fields.txt

[Michael Voronkov]

With Sub-Tasks it works, but not in a desired way: workflow transition is simply removed from the list of options. Desired way is to inform a user why an action is not allowed. I will be flooded with questions why people can't move things around.
Could you suggest a better way?

[Fidel Castro Armario]

What //JIRA Workflow Toolbox// shows is a mixture of //custom fields// and what it calls Virtual Fields. These virtual fields present some issue characteristics like if they were actual fields. Many of these virtual fields are treated internally (in DB) by JIRA as fields (not custom ones), but others are not (e.g., //Last comment's visibility//, //Assignee's full name//, //Assignee's email//, //Project key//, etc).

Those //Virtual Fields// which have a corresponding internal field in JIRA DB doesn't need to share exactly the same name of other characteristics (in the case of //Issue Resolution//, it corresponds to internal field //Resolution//) because they are created by the plugin, although they correspond naturally to a internal field in JIRA.

I hope I have answered your first question.

[Fidel Castro Armario]

I suggest you to use "Validators" instead of "Conditions". You can use "Validation based on regular expression" and "Validation on subtasks". Both work exactly the same way as its condition versions, except that they have an additional parameter Message to show when validation fails, to show the user when the validator fails.

In the following screenshot I show you where to find validator's tab in transition configuration screens:

[Michael Voronkov]

Hi Fidel, wanted to let you know that everything works now. Thanks for the help.

[Fidel Castro Armario]

Issue #33 was marked as a duplicate of this issue.