Can the order of validators be altered?

[Payne]

I have added a new validator to a workflow transition, so it is at the end of the list and is the last one to execute. I'd like for it to execute before some of the other validators, but I see no way to alter their order. Is this possible, short of exporting the workflow, modifying the XML, and importing (and it seems that I cannot overwrite the existing workflow during an import, so I would need to do some fiddling there)?

Thanks!

Payne

[Prakhar Srivastav {Appfire}]

@Payne

The order of the validator does not matter hence there is no option to change the order.

It is like if any of the validator fails then the operation will fail.

What you want to achieve with reordering the validator?

Regards

Prakhar

[Payne]

If my newest validator (purpose of which is to prevent users in a particular group from creating issues of a particular type) fails, all the other validators are moot, thus I wish for it to be the first one to execute.

[Nic Brough -Adaptavist-]

That's mildly efficient, saving you some CPU cycles, but you'd waste far more cycles implementing something to let you move them around.

You really don't need this, it's irrelevant.  Your validator will work fine, where-ever it is in the flow.

[Payne]

My purpose is for end user experience. The new validator allows creating Issue Type A only if the user is a developer or business analyst; business users should not create issues of that type. So what happens is:

Business user chooses the wrong issue type.

He doesn't make a selection for our "Security-related" dropdown because he doesn't understand what it means (it's meaningful to developers and BA's). The required field validator forces him to make a choice, so he guesses and chooses something.

He chose Expedited for the Change Class, not understanding its meaning in the context of the issue type he is not supposed to be creating. By doing so, a validator forces him to enter a planned date and backout procedure. He's thoroughly confused now. But, he enters something.

He then tries submitting again, only to be told that he should not be creating this issue type. He switches to another issue type, and the security-related and change class fields are not present, so dinging him with those two validators was a waste of his time and only aggravates him.

If the first validator to execute was the one to make sure he didn't choose that issue type, he would not have gone through the headache of the other two validators. That's why I wish for it to be the first one to execute.

[Nic Brough -Adaptavist-]

In terms of end user experience, it's no excuse.  You're already confusing and irritating them by blocking them using a particular issue type in this way, irrespective of the order you reject them in.

 That's not a good use-case and hence it's pretty much irrelevant in terms of usefulness of ordering validators.

If you stick with this poor design, that's no problem, your admins can work around it by deleting and then re-adding the validators in the right order.

[Payne]

How else would you suggest that I prevent creation of a particular issue type by a particular role? I found a solution offered as part of the ScriptRunner add-on, but it has been broken for some time per this Adaptavist issue.

[Jens Kisters __SeibertSolutions]

I am also interested in changing the order as i am currently trying to find out how much time my validators consume.

I was thinking about putting some scripted validators in there with some logging output.

i will try to work around the problem by copying the workflow, 

deleting all validators and then adding them back again in my preferred order (using the copy function of the Jira Admin Toolbox)