How to make a cascading field second level required only if second level there.

Teja, for your case where items might be childless... When the HashMap only has only selected item, you can pass its ID to OptionsManager.findByParentId(Long).  If that's not empty, it means the item has children that the user should have selected so you can make your validator fail.

How to make a cascading field second level required only if second level there.

A

A1, A2

B

B1, B2

C

No second level

Try using this slight variation:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue

def issue = issue as MutableIssue
def cascadingSelect = ComponentAccessor.customFieldManager.getCustomFieldObjects(issue)?.findByName("Cascading Field Name")
def values = issue.getCustomFieldValue(cascadingSelect) as HashMap

// Will return true if both the parent and child options in the Cascading Select have a value
def keySetSize = values?.keySet()?.size()
keySetSize == 2

I have added the last link in the workflow in the creation field and somehow the code is not working for me.
The script is not showing any error in the logs but the transition pass

I used the code posted by @David Lawless, and it worked fine. No errors. Just input your custom field name here: findByName("CascadingSelect")

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue

def issue = issue as MutableIssue
def cascadingSelect = ComponentAccessor.customFieldManager.getCustomFieldObjects(issue)?.findByName("CascadingSelect")
def values = issue.getCustomFieldValue(cascadingSelect) as HashMap

// Will return true if both the parent and child options in the Cascading Select have a value
values?.keySet()?.size() == 2

Using Jira 7.10 I have been trying to get the ScriprtRunner workaround referenced above, namely adding

"cfValues.get['your_ cascading_field_name']?.key.set()?.size() == 2" as a simple scripted validator.

https://scriptrunner.adaptavist.com/4.3.4/jira/recipes/workflow/validators/simple-scripted-validators.html#_validating_cascading_selects

However I found this returned the following error - 

[Static Type Checking] - Cannot find matching java.lang.Object#keyset(). Please check if the declared type is correct and if the method exists. Possible solutions: getAt(java.lang.String) @ line 1, column 1.

I raised a ticket with Adaptavist and was told "Static type checking errors can sometimes be ignored, and this is one of those cases. The code should still work fine, even though an error is shown. That being said, you can try using this code instead and seeing if that gets rid of the error:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.MutableIssue

def issue = issue as MutableIssue
def cascadingSelect = ComponentAccessor.customFieldManager.getCustomFieldObjects(issue)?.findByName("CascadingSelect")
def values = issue.getCustomFieldValue(cascadingSelect) as HashMap

// Will return true if both the parent and child options in the Cascading Select have a value
values?.keySet()?.size() == 2

I haven't tried ignoring the static type error, but have tried the code provided and it worked a treat.  Hopefully may help someone

spent unnecessary cycles on this issues.  Atlassian is not providing enough details as to why child filed is not becoming mandatory.   Their answer is to purchase ScriptRunner is not acceptable.   Why are they even allowing Cascading select fields if they have this many issues.

Does the description to this ticket mean that this defect will never be in scope nor actually resolved?

@oruettinger Please note that since the status of this issue is "Resolved" it is no longer possible to vote...

Hi, 

The following has worked for us:

cfValues.get['your_ cascading_field_name']?.key.set()?.size() == 2

https://scriptrunner.adaptavist.com/4.3.4/jira/recipes/workflow/validators/simple-scripted-validators.html#_validating_cascading_selects

Hi saurabh & Dave
I'm using this script but it won't let me create the issue - it gives the error message I entered even if I select values in both cascading levels.
I used the exact same script validator.
Any idea?

Your assistance is much appreciated.

Ayelet

@saurabh - Fantastic tip! Thank you so much for providing this workaround. It's a pity we have to use third-party plugins to fix deficiencies with system field types, but at least this gets us where we want to go.

please add following simple script validator in project workflow.

cfValues['your cascading field']?.values()*.value.size() == 2
this works absolutely fine for us.

Any chance at revisiting this? We would like both fields made mandatory.

Thanks for everyone's feedback and votes.

We've taken a look and we've decided that we won't be implementing this feature in the near future. It's not that we don't think this is valid, but it is currently not high enough on our priorities to make it into a planned release/our roadmap.

Please note that votes is one of the determining factors that we use to plan our roadmaps, for a full description please read our blog post: https://answers.atlassian.com/questions/110373/how-does-the-jira-team-use-jira-atlassian-com.

We hope you understand and appreciate our honesty on these requests.

Thanks,
Otto Ruettinger
oruettinger @ atlassian dot com

It somehow seems to me these products are developed in breadth and not in depth.

I don't agree with this, but I will say that cascading select fields have been poorly supported for a very long time. I'm not sure if they were every fully supported throughout the product, but there have been problems using importers, gadgets, etc. with this type of field for at least 5 years. I'm starting to see slow progress on some of these issues. For example:
https://ecosystem.atlassian.net/browse/JIM-787
https://jira.atlassian.com/browse/JRA-6411

Perhaps Atlassian is finally making an effort to bring this field type up to the same functionality as others...

It somehow seems to me these products are developed in breadth and not in depth.

I second Adhip comments.

Any comments from Atalssian on when this feature would be implemented? It was created in 2006 and is left open since then. Can we get a clear answer if this will ever be implemented? If not, i'd suggest to close the issue and not confuse customers leaving it in the open status.

Thanks

@Eva - Jamie has posted a corrected line (note '?'):

cfValues["myCascadingSelect"]?.getKeysAndValues()?.size() == 2

Actually, I posted this question on the Answers forum and Jamie suggested an much easier way: all we have to do is add validation on create with the following line:

cfValues["CascadingSelect"].getKeysAndValues().size() == 2

Now you NEED to install teh Script Runner to get this running though, but it works like a charm for 4.4.1.

More information in here: https://answers.atlassian.com/questions/17148/workaround-solution-for-making-2nd-drop-down-required-in-multi-cascade-custom-field

Please let me know whether this issue has been resolved. Since we need to do apply it urgently to one of the project in JIRA 4.3.4.When we select a value from the parent option, can the child value be also made mandatory.

The possible workaround previously mentioned does work. The only problem I have found with it is if you have some parent options with child options, and some parents without. The parents without at least one child will not validate if using the Fields Required validator, even if "None" is selected.

We just upgraded to JIRA 4.0.2, and ran into this issue.

Possible workaround: I'm on JIRA 4.0.2 and I've found that the Fields Required validator (JIRA Suite Utilities plugin) validates the presence of both fields.

So a workaround would be to apply the JIRA required setting in the field configuration so the field looks mandatory and back it up in the workflow with the Fields Required validator to check the second selection is also filled in. Obviously it won't prevent someone later editing the issue and blanking out the second selection but it's a start (maybe don't put the field on the edit screen so it can only be changed via a workflow transition screen).

Cascading Select is really stored as a multiselect field with 0, 1 or 2 values. If there is one value then that is the parent option. If there are two values then one is the parent and one is the child.
Making this field required as Nic wants means saying that it must have either 1 value that is allowed to not have children, or 2 values. To implement this would require a new field in the OptionConstants class I think.

The simpler way would be to create a custom field that inherits from the CascadingSelectCFType class but that requires two fields be set. To change what "required" means for a custom field, override
getValueFromCustomFieldParams() and return null if there aren't two Options.

I'm not sure this is quite right - I definitely need to be able to make the sub-selection mandatory, but I've also got cases where we do not want it mandatory (whilst keeping the main selection mandatory)

A more difficult case (which I wouldn't expect to see implemented because I suspect it would be horrible to do) would be a mix, where some sub-select fields would be mandatory!

Both components of a cascading field should be required if the required option is selected. It would be counter intuitive to not make it so.

The only other option would be to allow different options for each level.

Looking forward to getting this fixed.

Thanks!
-mm

(possible cause as per note in JRA-6411)

I agree with Simone.

The cascade comes together as a custom field - If the custom field is set to mandatory, then BOTH dropdowns should require a value.

Please can you advise how we can make this mandatory, or when it could be implemented in JIRA?

regards,
Paul

I would say that this is not an improvement but a bug. I set a cascading select custom field to "required" in the field configuration and expected both fields to be mandatory then. It is very important for us that the custom field behaves like that.