before moving an issue to "resolved" some conditions have to be met (e.g. a checkbox of a custom field has to e checked). In case of unmet conditions I'd like JIRA to show a message before the resolve issue dialog opens.
I've already come up with some solutions but I'm not completely satisfied
Do you have any other suggestions?
Thanks in advance
Unfortunately, there is no middle ground; either a condition blocks it silently, or a validator processes it after one tries to submit it.
I had a discussion about this a couple of weeks ago, and I had suggested that JIRA have a 'pre-validator'. That has been rejected as overly complicated; the flip side of that would be to have an option on 'condition' that, instead of blocking a transition, provides feedback when you attempt to initiate it. That suggests that maybe they should consolidate 'condition' and 'validation' such that the feedback and 'check point' is sufficient to cover all cases (provide feedback or block, and pre or post submission).
Now that I've written that, I do see one way to make this work. A 'validator' that has no screen associated with it is effectively a 'pre-validator'. All you'd have to do is create two separate transitions based on the condition for the custom field such that only one appears at a time; for the one with the condition that would otherwise have blocked the transition, remove the screen and use the validator to provide feedback. For the one with the condition that would not have blocked the transition, only validate if the screen allows them to remove some of the previously met conditions.
The trick there is that you'd want both transitions to show up with the same name; if you are using "Resolve Issue" as the value, you can use workflow properties (https://confluence.atlassian.com/jira/workflow-properties-189949.html) to set the label and button. The properties are "jira.i18n.submit" and "jira.i18n.title"; you can get the values from the built-in Resolve Issue transition, but I think they are "resolveissue.submit" and "resolveissue.title". Those are keys that map to language-specific values. If using something other than that label, I'd just try to make them very similar; perhaps an extra space somewhere would make them unique enough to co-exist in the workflow, while still providing the same look-and-feel in the UI. Or maybe add (blocked) to the one that failed the condition; if they see (blocked) and understand the reason, they don't have to click on it but, if they do click, they get the feedback.
I'm totally going to use this; I already have multiple "Resolve" and "Close" transitions so that different issue types have different resolutions (jira.field.resolution.include workflow property). I'll just add a "Blocked Resolve Bug", "Blocked Resolve Issue", etc, transition with no screen, and move the validators that aren't available on the screen to the new transition. One of my program managers expressed the same concerns you did, but, at the time, I hadn't managed to come up with this possibility. Thanks for making me think through it one more time.
There's a couple of things going on here –
The use-case for this scenario is the Validator. Conditions are designed to be silent. The problem is that JIRA doesn't visibly mark the issue or let us indicate the Validation pre-submission.
You can assign a screen which works well, but users unfamiliar with the process won't know a field is required until submission.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG