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

[Keith Champoux]

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!

[Keith Champoux · Accepted solution]

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?

[JamieA]

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.

[Keith Champoux]

Thanks a lot Jamie. I've reported https://jamieechlin.atlassian.net/browse/JBHV-233 about this.