Hi @kkercz, thanks for your reply.
I’ve set up what you said but it did’t work. Could you take a look and tell me if I am missing something?
Sorry to add the screenshots in this way, but as “new user” I can only attach one image:
If I remove the validator the issue is created normaly.
Thank you very much for your support.
Best regards,
Emilio
That was a bug for all Jira expression validators on initial transitions in Service Desk projects. It has been fixed now.
Confirmed, it’s working fine now 
Thanks again!
This thing is great. We were waiting for the feature for a long time. Just to make sure, is there a way we can provide a classname (like we can do in server apps) or a rest endpoint in the expression which will evaluate the validator ?
No, you need to provide a Jira expression that returns true (to allow the transition) or false (to reject). You can also build the expression dynamically on a configuration page (as described in the documentation).
Thanks for the info @kkercz. Do you have any plans in the future to implement something of this sort ? I can certainly create a ticket for the same if nothing exists.
We don’t have any such plans, because:
I should be able to provide some guidance if you shared what kind of validator you would like to create.
Hi @kkercz - we’ve noticed that Conditions and Validators don’t get applied on the Create Issue transition, is this expected? Can we have a ticket raised to have that fixed?
They are supposed to work, and they did the last time I checked. Please raise a ticket with a list of steps to reproduce.
Any chance we could get the following information added to the context that conditions and validators have access to?
The use case is providing the option to enable/disable the conditions or validator without having to delete it from the workflow configuration.
At the moment, if the condition or validator is disabled, we return an expression of true to Jira, however, if the workflow has the “any of the following conditions” option selected, then we would want the “disabled” condition/validator to have returned false as the expression for Jira to use (unless its the only condition/validator for the transition…). As you can see, the logic gets complicated.
Alternatively, if there is some other mechanism by which we could indicate to Jira that a condition or validator should not be processed, then that would be even better.
I think this kind of information should be included in the workflow configuration returned by the Get workflows API. If it was, would it help with your use case?
We’ll need to know at runtime what the value of that option is, and how many other conditions/validators there are in order to always return the right value for a “disabled” condition or validator.
Given that we can’t make REST API calls from Jira Expressions, we’ll need another way to establish that information in order to implement this feature properly.
I suppose you could get that information from the API, store it in an app property and then get it at runtime from there 
We could, but if the value of that option changes without the customer remembering to resave each condition/validator then the value in our saved config would be out-of-date…
@kkercz - For the improvement Jon mentioned above, would it better for us to raise this as an improvement request to the ACJIRA board?
Many thanks,
Ryan
Yes, I would say it’s always a good idea to report feature requests as ACJIRA tickets. That allows us to gauge interest (by looking at the number of watchers and votes) and prioritise accordingly.
Hi, I realize that this is an older post but I was not having any luck posting this as a separate topic. I have two questions:
First I was wondering if it is possible to create a condition or validator that does not have an edit or create view. I have a very straightforward validator that does not need any configuration and don’t want my users to be directed to an empty page just to click on the add button
Second I can’t seem to find how the submit buttons are intended to be used with Javascript API. I end up needing my own button to save the configuration as the add button will leave before the trigger can be executed, the configuration validated, and stored and this seems like a terrible User Experience.
Hello, @MichaelIlewicz 
Yes, its’ possible, just don’t declare them in your descriptor.
Have you tried the example app?
Thanks for the response, when I first tried leaving it empty I got an error 500 response but it seems to be working fine now. I am using React and node.js so I tried to understand the post function example using that but that was less then helpful. With this example I was able to come up with a solution for React, thanks!
for anybody else looking for a nice way to configure with React, I created a wrapper in which I then use atlaskit fields and use the onChange event to write to ref.current rather than using getElementById
import React, { useEffect, useRef } from "react";
import Form, { Field, HelperMessage } from "@atlaskit/form";
declare const props: { id?: string; config?: any };
export default function ConfigWrapper<ConfigType>({children,validate, dependencies}: {
children: (contextRef: React.MutableRefObject<Partial<ConfigType>>) => JSX.Element;
validate: (config: Partial<ConfigType>, ...dependencies:any) => string|undefined;
dependencies?:any[]
}) {
const ref = useRef<Partial<ConfigType>>(props.config || {});
useEffect(() => {
if (!dependencies?.some((dependency:any) => dependency == undefined)) {
AP.require(["jira"], (jira: any) => {
jira.WorkflowConfiguration.onSave(() => JSON.stringify(ref.current));
jira.WorkflowConfiguration.onSaveValidation(() => !validate(ref.current, dependencies));
});
}
}, [dependencies]);
return (
<Form onSubmit={() => {}}>{({ formProps }) => <form {...formProps}>{children(ref)}</form>}</Form>
);
}