Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Required field validator on create transition doesn't work

Simone Kaden June 1, 2022

Hello everyone,

i want to add a validator on the create transition of a workflow. For a request type a few fields should be marked as required when creating a request from the jira backlog (not the portal) no matter how i am configuring it it just won't work.

Everytime I am testing the validator while configuring it with existing issues it works. but when a new issue is created it just won't.

i have tried writing my own script via jmwe:

!(!!issue.customfield_10010 && issue.customfield_10010.requestType.id == '325' &&
(issue.customfield_10424 == null || issue.customfield_10414 == null || (! issue.customfield_10004 || ! issue.customfield_10004.value) || (! issue.customfield_10162 || ! issue.customfield_10162.value))
)

and I tried to add a validator for every single field (screenshot) nothing worked.image.png

Can anybody help me?

 

Best regards

Simone

2 answers

0 votes
David Fischer
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 6, 2022

Hi @Simone Kaden ,

this is caused by a know Jira issue: the correct customer request type is not set on the issue when Validators run on the Create transition. See https://ecosystem.atlassian.net/browse/ACJIRA-2532

I recommend you open a support request with Atlassian and tell them that you are impacted by this bug.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 1, 2022

The obvious question is "why not make the fields mandatory in the field configuration"?  This shouldn't affect the requests as field config is for issues, not requests.

Ignoring that, I can do a bit of explanation, but not help a lot.  Validators check that data is set before allowing a transition.  They have that data when transitioning issues, but when creating issues, they don't actually have anything.  The expression in your code works with data current;y on the issue and how it changes, but there is nothing there when you are creating an issue!

Your code needs to be looking at the entered data, not the data on the issue (that isn't yet there).  I do not know if JMWE has a way to do that.

Simone Kaden June 2, 2022

Thanks for your answer! For the issue type there are several request types but only one of them should have certain fields marked as mandatory in the backend. Therefore i cannot use the field configuration.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 2, 2022

Er, you can have different field configurations by issue type.  Check the project's field configuration scheme.

Simone Kaden June 2, 2022

yes of course. But the issue type "Service Request" can only have one field configuration, right? So with my issue type there are at least 5 different request types which all use different fields and all of them need different fields to be marked as required. And that is something i cannot do with the field configuration scheme.

I don't think you are getting my point, but thats okay.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 3, 2022

Yes, but that's the point - different service request types can be backed by different issue types, which can have different field configs.

You can set up

Service Request type 1 ->  Issue Type 1 -> Field configuration 1 with mandatory fields

Service Request type 2 ->  Issue Type 2 -> Field configuration 2 with only summary mandatory

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events