Hello everyone!
How do you think, is it possible to split a cascading field into two fields, the first of which will be responsible for the parent value, and the second for its child? Both with drop-down lists?
Now I managed to make such a list only for the parent element. But I had difficulties when trying to make a field so that the child depends on the parent and displays only the necessary options.
Has anyone implemented similar examples?
Below is a script that displays the parent values of a cascading field.
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.customfields.manager.OptionsManager
import com.onresolve.scriptrunner.canned.jira.fields.model.PickerOption
def customField = ComponentAccessor.customFieldManager.getCustomFieldObject("customfield_ID_CASCADING")
def optionsManager = ComponentAccessor.getComponent(OptionsManager)
def config = customField.getConfigurationSchemes()*.oneAndOnlyConfig?.find()
if (!config) return []
def parentOptions = optionsManager.getOptions(config)?.findAll { it.parentOption == null && !it.disabled } ?: []
// Search
search = { String inputValue ->
parentOptions.findAll { it.value.toLowerCase().contains(inputValue?.toLowerCase() ?: "") }
.collect { [id: it.optionId.toString(), name: it.value] }
}
// Option
toOption = { Map item, Closure highlight ->
new PickerOption(
value: item.id,
label: item.name,
html: highlight(item.name, false)
)
}
getItemFromId = { String id ->
def opt = parentOptions.find { it.optionId.toString() == id }
if (!opt) return null
[id: opt.optionId.toString(), name: opt.value]
}
renderItemViewHtml = { Map item -> item.name }
renderItemTextOnlyValue = { Map item -> item.name }
The simplest way I would suggest is by using ScriptRunner's Server-Side Behaviour.
Where the Server-Side Behaviour will be added for the first Single Select List (which functions as the parent cascade field), and based on the option selected from the First List, the options on the Second List will be filtered.
I have provided a similar solution for this in this Community Post.
Let me know how it goes.
Thank you and Kind regards,
Ram
One remark here: The script is stored on server-side, but the execution is still happening on the client-side. That means, the behaviours do only work as long as client-side JavaScript is enabled.
While this often is the case, it might not be in certain environments, which can cause data integrity issues, if later processes rely on that data. That is why I only made a little notice about that in my post.
If this is only for assisting user inputs and increase user experience there is no argument against using those behaviours.
Besides that, I have also implemented such field behaviours and they do work perfect if JavaScript is enabled on all clients.
Regards,
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's the point of Behaviour. The groovy code is implicitly converted to JavaScript at runtime.
You also mentioned:-
One remark here: The script is stored on server-side, but the execution is still happening on the client-side. That means, the behaviours do only work as long as client-side JavaScript is enabled.
While this often is the case, it might not be in certain environments, which can cause data integrity issues, if later processes rely on that data. That is why I only made a little notice about that in my post.
If this is only for assisting user inputs and increase user experience there is no argument against using those behaviours.
If the goal is to filter the options of a Single Select List using another Single Select List, this can only be done using Behaviour.
Scripted Fields is not able to do this as it is only able to work on the view screen, not the Create / Edit or Transition screens, where the filtration can be done.
Thank you and Kind regards,
Ram
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am not sure on how to achieve this with a custom scripted field, but there is a way of handling such a behavior if you are also running Jira Service Management: Assets.
With Assets you can create two independent fields that are both relating on Asset Object Types. And the objects within these types can have relations to other objects.
That being said, Jira is capable of creating custom fields for Asset objects and have them being related to each other.
The "parent" field would be a common Asset custom field, while the "child" would be a Referenced Assets custom field. See more information on this: Referenced Assets custom field | Jira Service Management Data Center 10.6 | Atlassian Documentation
Besides that, I could imagine making use of Behaviours of ScriptRunner so that if the parent select list is updated, the child select list is modified to only display the available values. However, as Behaviours is based on JavaScript execution in the browser, this would not really be a suggested way if data integrity is key. See more information on the Behaviours here:
Hope this helps!
Stefan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.