I’m happy to announce that we’ve just released the workflow validator module for Connect apps, which joins the workflow condition module that was introduced a few months ago.
To declare a condition or validator, the app needs to provide a Jira expression that will control its behvaiour. Jira expressions are a domain-specific language evaluated on the Jira side, which makes it possible for conditions and validators to be executed synchronously, without any remote calls.
Keep in mind that after a Connect app adds a validator or condition, it still needs to be added to a transition by Jira admins, just like any other (built-in) condition or validator. They are not applied automatically to all transitions.
Looking forward to hearing your feedback and seeing all the amazing things you will be able to build with this!
If I publish the workflow anyway and try to test the validator, it seems to work (it blocks transition Done) but Jira handles it incorrectly (displays strange message instead of my error message):
@kkercz
Hi there. I’ve managed creating validators and conditions with static expressions and these are working just fine. Now, I’m looking for a possibility to use dynamic values to filter (match) for in this expressions, e.g.: a status value, which could be defined dynamically while adding such a condition/validator to a workflow.
If one is working with postfunctions there is this “create” page where one could edit and post the parameters being used. Is there such a “create”/”edit” page for conditions/validators? Or is there an alternative way of passing posted parameters to this validators/conditions expression?
Currently it’s not possible to have a configuration page for workflow validators or conditions. However, this is on our roadmap. I will keep you posted.
You can still make your expressions dynamic to some extent, by using entity or app properties. But I realize this isn’t a good fit for all use cases.
There is no specific time frame. If I had to guess, I’d say a month or two, but this is by no means any official promise, so please don’t build your plans around it.
I’m happy to say that we’ve just rolled out the possibility to add configuration pages for workflow conditions and validators. It works very similarly to post-functions and allows you to save a configuration object that will be available in the config context variable. Alternatively, you can provide an entire expression that will override the one from the descriptor.
Hi @kkercz,
that’s great news!
I have a suggestion for Validators though: just like the Jira expression can be “overridden” by the config page, the “errorMessage” should also be overridable by the config page, so that it can be specific to an instance of a Validator.
We have dynamic error messages for validators in our backlog
I’m currently leaning towards making it be possible to provide an expression in the descriptor to evaluate the error message. You could use the config context variable to make it dependant on the configuration (for example, by writing the expression as config.errorMessage and returning errorMessage in the config value object on the configuration page), but you could also build an expression that would evaluate the error message based on the current issue, depending on your needs.
We’ve just added dynamic messages for workflow validators. Hopefully without causing any bugs this time
When declaring an error message, you can either make it a static text, as before, using the I18nProperty bean, e.g.:
"errorMessage": {
"value": "The validator rejected the transaction",
"i18n": "validator.error.message.key"
}
Or provide a Jira expression that returns the error message based on context variables, including the current configuration, e.g.:
"errorMessage": {
"expression": "issue.key + ' does not have any comment that contains: "' + config.regexp + '".'"
}
Checkout an example app that demonstrates usage of configuration pages for both validators and conditions, and dynamic error messages for validators: Bitbucket
Hi @kkercz,
I have started building Conditions and Validators based on what you have implemented, and I am running into issues/missing features. What’s the best way to report them?
For example:
from Jira expressions, you can access the Epic of a Story, but not the Stories of an Epic (and the “links” field doesn’t return system links, so we can’t use that either)
if there is an error during the execution of a Jira expression in a Condition or Validator, neither the user nor the app are notified of the error. And since Jira logs are not accessible on Jira Cloud, there is basically no way to know why a Condition or Validator is not working. Would it be possible to send such errors to the app, using the same mechanism as the /triggered POST call made by Jira to trigger post-functions?
The best way to report such issues and feature requests would be through creating an ACJIRA ticket.
if there is an error during the execution of a Jira expression in a Condition or Validator, neither the user nor the app are notified of the error.
Well, the user just gets a rejected transition, which makes sense given that a failed expression definitely doesn’t return true. But it’s a good point that there should be some kind of mechanism for investigating such failures for app developers.
Webhook sounds reasonable; another option would be for Jira to save a log of failed evaluations and expose the list via a REST API.
Note that while there is a Conditions component on the ACJIRA project (which might actually not even be for workflow Conditions), there is no component for workflow Validators.