nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dynamic Checkbox Selection On Create

Harvey Bennett_suxbgj

Does anyone know if there is solution or plugin out there to load in checkboxes on the create screen that would be dynamic based on the logged in user. The checkboxes will be completely different based on the logged in user what each checkbox name would be. For instance if I'm logged in, I might see Suzy and Jill for my checkbox options. But if Bob logs in he might see Larry and Cindy as his checkbox options. I need this custom field to be dynamically loaded in and be able to be stored and referenced later on. The dropdown will have 1000's of possible combinations and will be changing rapidly so a static custom field with options is not going to be sufficient. I was hoping something existed where these could be "smart loaded in". The user might only select 1,2 of the options but those options should be stored in the Jira ticket.

Edit: I just need a way to capture this data and pass it off to a user picker field. They do not want to have to manually type and search for their users and would rather have them listed and they check a box next to that users name. I was going to use ScriptRunner to move that value into a real multi user picker field for data integrity purposes.

Accepted answers

PD Sheehan

That sounds like a decent use case for Select List Conversion using Behaviours

But instead of loading the list based on user input, you query the source (could be hardcoded or some remote data source) in the behaviour initializer and apply the options using setFieldOptions.

I don't think this can be formatted as checkboxes, it would still work.

For example:

import com.atlassian.jira.component.ComponentAccessor
def field = getFieldByName('Name Selection')
def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def sampleData = [
   [userName: 'Suzy', showFor: ['Harvey']],
   [userName: 'Jill', showFor: ['Harvey', 'Bob']],
   [userName: 'Larry', showFor: ['Bob']],
   [userName: 'Cindy', showFor: ['Bob']],
   /* ... add more ... */
] //this could be retreived from an external API or DB call

def usersToShow = sampleData.findAll{it.showFor.contains(currentUser.name)}*.userName
def optionsMap = usersToShow.collectEntries{[(it):it]}
field.convertToMultiSelect().setFieldOptions(optionsMap)

In my example, you will see Suzy and Jill, but Bob would see Jill, Larry and Cindy.

The sample data structure could be reversed if that matches your case better.

All comments

PD Sheehan

That sounds like a decent use case for Select List Conversion using Behaviours

But instead of loading the list based on user input, you query the source (could be hardcoded or some remote data source) in the behaviour initializer and apply the options using setFieldOptions.

I don't think this can be formatted as checkboxes, it would still work.

For example:

import com.atlassian.jira.component.ComponentAccessor
def field = getFieldByName('Name Selection')
def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def sampleData = [
   [userName: 'Suzy', showFor: ['Harvey']],
   [userName: 'Jill', showFor: ['Harvey', 'Bob']],
   [userName: 'Larry', showFor: ['Bob']],
   [userName: 'Cindy', showFor: ['Bob']],
   /* ... add more ... */
] //this could be retreived from an external API or DB call

def usersToShow = sampleData.findAll{it.showFor.contains(currentUser.name)}*.userName
def optionsMap = usersToShow.collectEntries{[(it):it]}
field.convertToMultiSelect().setFieldOptions(optionsMap)

In my example, you will see Suzy and Jill, but Bob would see Jill, Larry and Cindy.

The sample data structure could be reversed if that matches your case better.

Harvey Bennett_suxbgj

@PD Sheehan This is promising. The user list is actually local to Jira. So my list is generated based on a JQL response returned against my user profile. I would see if my name is listed as a supervisor on that list and in a separate custom field I'm tracking users that I manage. So this other custom field with the users that I'm manage I could preload with their usernames into the userName (key,value) map). Looks fantastic.

This does look like it can be manipulated by Behaviors/Initializer using ScriptRunner but I'm curious how you are storing values in that field without it being defined in the Field Configuration Scheme? Wouldn't all the names need to be defined up front in order for it to be stored in that custom field? Wouldn't I lose the values stored on create if they aren't defined as possible options? I also do not know if I want possibly 1000's of options being stored in a custom field for performance reasons?

If it was multiselect that would work for me too, just needs to be see something where the supervisor would not need to know the names of the top of their head (so a list of some sorts).

PD Sheehan

convertToSingleSelect and convertToMultiSelect methods in behaviours work with free text fields only.

They just convert the UI to behave differently. The underlying data stored will be the key of the options map. In the case of Multi conversion, the data is a semi-colon separated string like: "Suzy; Jill; Larry".

This isn't great from a search/indexing standpoint.

But if you are going to use the data downstream in some other automation, you just have to tokenize the string.

For example in a workflow transition using a scriptrunner condition, validator or postfunction, you would get the data like this:

import com.atlassian.jira.component.ComponentAccessor
def nameSelectionCf = ComponentAccessor.customFieldManager.getCustomFieldObjectsByName('Name Selection')[0]
def selectedNames = issue.getCustomFieldValue(nameSelectionCf)
selectedNames = selectedNames.tokenize(';')

def selectedUsers = selectedNames.collect{ComponentAccessor.userManager.getUserByName(it)}

If searching and indexing are important to you, then you would need to somehow load /refresh all your options in the configuration (can be done with a script job that runs daily) and use a variant of what I shared to filter the available options at runtime.

But performance on that would not be great. Behaviours run on the browser side first. So the form would have to load all 1000+ options, then send a request to your serverside script to ask for the filtered list. Then the browser-side javascript would update the list options to just those returned by the server-side script.

Harvey Bennett_suxbgj

@PD Sheehan This makes sense. I've been trying to play with this on and off when I can. Any reason why this would not convert it to appear as a multiselect field? I have my text field that I'm trying to convert on the create screen. It's is a multi-line text field.

def field = getFieldByName("Users To Manage") // Multi-line text field
field.convertToMultiSelect()

Any ideas why this would still be a text box?

Thanks for your assistance

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

scriptrunner

jira

jira-server

data-center