How to properly use Behaviours plugin to hide a field based on other field's value

My goal is to hide one field (PlatformCategory) based on the value of another field (Product/Component), whereby the PlatformCategory field will only be visible when Product/Component = "Platform". Ideally, this should work correctly on the initial Create Issue screen (field hidden because Product/Component is initially null), as well as on the initial drawing of the Edit Issue screen (field hidden or shown based on the current Product/Component value).

Based on the example documention from Jamie (https://jamieechlin.atlassian.net/wiki/display/JBHV/Miscellaneous+Behaviours+Examples#MiscellaneousBehavioursExamples-Showorhidefields), I originally configured the following:

Create new Behavior:

  • Name = Hide Platform Category Programmatically
  • Description = Hide the Platform Category field unless Product = Platform
  • Add Field "Product/Component"

Add serverside script:

FormField ProductValue = getFieldById ("customfield_11512") // id for Product/Component

FormField PlatformCategoryName = getFieldById ("customfield_11401") // id for PlatformCategory

String producttype = (String) ProductValue.getValue()

if (producttype =~ /12946/) { // id from initial part of Cascading Select "Platform"

 PlatformCategoryName.setHidden(false)

}

else {

 PlatformCategoryName.setHidden(true) 

}

Add Mapping:

  • Behaviour ID = Hide Platform Category
  • Issue Types = Any issue type
  • Projects = All

This seemed to work fine, except that on the initial drawing of the Create Issue screen, the PlatformCategory (that I wanted to be hidden) was initially visible (but would become hidden/unhidden based on Product/Component as desired, once a value was selected in that field).

After playing around a bit, I realized that I could create a separate behavior on the dependent PlatformCategory field, setting the field to hidden, and then allow the server script on Product/Component to drive whether PlatformCategory should be shown or not.

This solves the Create Issue scenario, but breaks the Edit Issue scenario, because the PlatformCategory will always be initially hidden when using Edit Issue, even if the Product/Component is actually "Platform". Basically, it seems that the server script that is attached to the field only gets executed if the user modifies the field value, and only then does the dependent field logic works correctly.. Is there some way to cleanly implement this so that the dependent field is always correctly shown or hidden?

Thanks for any help!

2 answers

1 accepted

Accepted Answer
0 votes

After playing around further, it seems that to receive the complete implementation, it works to add the identical server-side script on both the main field as well as the dependent field:

  • Changes to the value in the main field itself are handled by the script on the main field
  • Initial page draw (properly hiding/showing the dependent field) is handled by the script on the dependent field

In this way, during Create Issue the dependent field is initially hidden (as is correct), and during Edit Issue the dependent field is either initially shown or initially hidden based on the field value at page draw time. I think this solution might be hinted at on https://answers.atlassian.com/questions/183906/how-to-get-the-current-actual-change-value-in-the-form-field and https://jamieechlin.atlassian.net/wiki/display/JBHV/JIRA+Behaviours+Plugin (comment from Jamie on Mar 21, 2011)

This seems a bit convoluted to me, but maybe this is how everyone has implemented field hiding/showing?

1 vote

Hi Keith,

The way you think it should work, is the way that it should work. That is, you should not need to apply it to both. Maybe there is a bug with cascading selects triggering their listener when the page firsts loads... but I thought this worked. If you are using jira 6, and the latest behaviours plugin, please feel free to create a bug report in the usual place...

BTW, if for some reason you do need to apply the same script to multiple fields, it's probably best to refer to a file on the server. Although this can be a bit more hassle.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Sep 18, 2018 in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

22,334 views 2 7
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you