Making a custom field required based on the value from another custom field
Hi,
Use Case: Two custom fields
- Test1 – Check box
- Test2 - Text field (<255 characters)
Can we make Field #2 (Test2) required if Field#1 is checked (i.e. Test1 is checked)
In other words, if the Test1 Checkbox is checked, prevent users from creating the JIRA ticket until they enter something in the Test2 field.
Is it possible to do something like this?
Comments (29)
-
repo owner -
reporter Hi Fidel,
Thanks for your help. Let me try this configuration in our test environment and see if it works as expected.
--Adhip
-
reporter Hi Fidel,
Not sure if i did it correctly but i am getting a error in trying to create a issue now. Do i need to change the Numerical and Date-Time Terms and Text- String Terms as i have highlighted in the attached screenshot?
--Adhip
-
reporter -
repo owner Hi Adhip,
You should use the field codes which are automatically injected using the select list below TEXT-STRING TERMS (select the field and then click on Insert String Value). Those field codes have a format like %{nnnnn} where nnnnn is a numeric value.
-
reporter Hi Fidel,
Thank you. It is working as expected. Exactly what we needed. Thanks again.
--Adhip
-
repo owner - changed status to resolved
-
reporter Hi Fidel,
Another scenario. What if we are using a select list instead of a checkbox.
Example : We have a select list called 'Environment' and it has couple of options. If enviornment = production, we want a value entered for rapid release approval ticket number.
Is this the correct syntax?
%{Environment}= Production IMPLIES %{Rapid Release Approval Ticket Link}!= null
Or do we use the value number of the option 'Production' above.
-
reporter - changed status to open
-
repo owner Hi Adhip,
You should use the following boolean expression:
%{aaaaa} = "Production" IMPLIES %{bbbbb} != null
replacing aaaaa with field code for Environment custom field, and bbbbb with field code for Rapid Release Approval Ticket Link.
We write Production between double quotes because it's a string literal.
-
reporter Hi Fidel,
It works perfectly. Thank you so much.
--Adhip
-
reporter - changed status to resolved
-
reporter - changed status to open
Hi Fidel,
Another question on this. So, i found a workaround on this today. If you simply choose a different value for %{aaaaaa) instead of Production and create the issue, you can edit the ticket and change the value back to Production and the field %{bbbbbb} can still be left blank (ie null).
Is there a way we can implement this validator on edit issue as well just like create issue?
-
repo owner Hi Adhip,
The solution I can provide you requires to remove field Environment from edit screen, and force it to be edited using a reflexive transition that presents the user the field to be edited (for example creating a transition called "Edit Environment").
The solution in detail is:
1) Create a global reflexive transition called "Edit Environment". A global transition is available from any status, and a reflexive transition has the same origin and destination status. The following screenshot shows how to create these kind of transitions.
2) Remove custom field Environment from EDIT screen, so that nobody will be able to edit it directly. You should keep the field in VIEW and CREATE screens.If you are using the same screen for EDIT and VIEW operations, or for EDIT and CREATE operations, you will have to clone the screen and use different screens for each operation.
3) Create a new screen called "Environment edition", add field Environment to it, and associate to "Edit Environment" transition.
4) Add "Boolean validator with math, date-time or text-string terms" to "Edit Environment" transition with the following boolean expression:
%{aaaaa} = "Production" IMPLIES %{bbbbb} != null
replacing aaaaa with field code for Environment custom field, and bbbbb with field code for Rapid Release Approval Ticket Link.
-
reporter Hi Fidel,
Thank for you for the message. We do have two different screens. One for Create/ Edit and one for View. I may need to split the Create/Edit into two as well. One for Create and one for Edit. For now, i think we will just remove the options for editing the field 'Production' in the "Edit Issue" mode. We will try this complex solution only if need arises. Thanks for your help again.
-
repo owner - changed status to resolved
Yes, you should have to split CREATE/EDIT screens.
I close the issue.
-
reporter - changed status to open
Hi Fidel,
We need another help. Is there a way we can put a validator in place so the field %{bbbbbb} can only accept numerical values (ie no alphabets) when %{aaaaaa} = Production?
-
repo owner Use the following boolean expression:
%{aaaaa} = "Production" IMPLIES (%{bbbbb} != null AND matches(%{bbbbb}, "[0-9]+"))
-
reporter You are awesome. Works perfect, much appreciated.
-
reporter - changed status to resolved
-
reporter - edited description
- changed status to open
-
reporter Hi Fidel,
Hope all is well with you. I just wanted to check with you a small update related to the Boolean expression below
%{aaaaa} = "Production" IMPLIES (%{bbbbb} != null AND matches(%{bbbbb}, "[0-9]+"))
if we want the field %{bbbbb} not equal to the reporter in the 2nd part of the expression above %{aaaaa} = "Production" IMPLIES (%{bbbbb} != null AND matches(%{bbbbb} , how would the expression look? Since Reporter is a out of the box JIRA field and not a custom field, do we use the its value or hard code in the name "Reporter"
%{aaaaa} = "Production" IMPLIES (%{bbbbb} != null AND (matches(%{bbbbb}!="Reporter"))
Is this correct?
-
repo owner Hi Adhip,
It depends on whether the value expected at %{bbbbb} is a user name or a user's full name. Maybe you also want to make your expression to ignore the case, and any leading or trailing space. This is particularly important when the value is manually entered by a user.
Try this expression:
%{aaaaa} = "Production" IMPLIES trim(toUpperCase(%{bbbbb})) not in [toUpperCase(%{00006}), toUpperCase(%{00005})]
where %{00006} is field code for Reporter and %{00006} is field code for Reporter's full name.
-
reporter Hi Fidel,
The custom field %{bbbbb} is a user picker (querying our active directory). For me, the value is apokharel (Full Name : Adhip Pokharel). We do not have a reporter in the create issue screen. Please see below as how it's displayed after creating the JIRA ticket.
--Adhip
-
reporter This is the 1st part of the expression
%{10201}="Production" IMPLIES %{15900}!= null
where 15900 = ID for a user picker field called 'Reviewed By'
We need to include the 2nd logic (%{15900} is not a reporter) and combined the two expression into a single one.
Please let me know if you have any questions
-
repo owner Use the following boolean expression:
%{10201} = "Production" IMPLIES (%{15900} != null AND %{15900} != %{00006})
-
reporter Thank you. I will test this early morning tomorrow and let you know how it goes.
-
reporter Hi Fidel,
It worked perfectly as we were hoping for. Thank you so much again. Have a great day!
--Adhip
-
reporter - changed status to resolved
- Log in to comment
Hi Adhip,
You should add "Boolean validator with math, date-time or text-string terms" validator to "Create Issue" transition with the following boolean expression:
replacing aaaaa with field code for Test1 custom field, and bbbbb with field code for Test2 custom field.