Select list when the incoming value is not in the same case of the select list options

[elyashiv.grosser]

In jira, I want to select a value from a select list.
The select list is a list of emails in all sort of lower\upper\camel cases.
The input is in a random case.

I need to find the input inside the value list and then choose it and assign it to the issue.

example:
input: Example@mail.com

list:
example@Mail.com
apple@mail.com
Exam@mail.com

Find “Example@mail.com” in the list, even though the case is different.
I thought using this, but it didn’t work.

def default_value = nodeHelper.getOption (issue,“emails”,apple@mail.com")
def emails_options = nodeHelper.getOptions(issue,“emails”)
def matchingOption = emails_options.find { option →
option.value.toLowerCase() == replica.input?.toLowerCase()
}
issue.customFields.“emails”.value = matchingOption ?: default_value

[Majid]

Hi @elyashiv.grosser ,

A very warm welcome to the community!

If the issue is only converting the cases, you can convert both to lower case and then compare them e.g. use the toLowerCase() groovy method.

Hope it helps1

Thanks
Majid

[elyashiv.grosser]

Hi @Majid
Using toLowerCase() isn’t enough, since both the list of options and the input value are not in lowerCase in the 1st place.

If I lower only 1 side, the getOption won’t work. I need a way to lower both sides.

[Majid]

Ah I see your point. So the getOption() wont fetch the correct option as it might not even be in lowerCase. interesting challenge.
Let me have a play around with this today to see if we can craft something?

Are you doing this on a Jira Cloud instance, in a software project?

[elyashiv.grosser]

Hi @Majid
Thanks for your help!

I’m using both jira cloud and jira DC (on-prem).
This is my current solution, it’s using the general Jira API and it’s long. I hope there is something more simple:

def default_value = nodeHelper.getOption (issue,“emails”,apple@mail.com")
def ComponentAccessor = com.atlassian.jira.component.ComponentAccessor
def optionManager = ComponentAccessor.getOptionsManager()
def customField = ComponentAccessor.getCustomFieldManager().getCustomFieldObject(“customfield_xxxxx”)
def jiraIssue = ComponentAccessor.getIssueManager().getIssueObject(issue.key)
def fieldConfig = customField.getRelevantConfig(jiraIssue)
def emails_options = optionManager.getOptions(fieldConfig)
def matchingOption = emails_options.find { it.value.equalsIgnoreCase(replica.input?.value) }

issue.customFields.“emails”.value = matchingOption ?: default_value

[Majid]

Well, an easy way is to just create a mapping e.g.

def TestMap = [
“source” : “destination”
]

So that the cases wont be an issue anymore, but let’s try to do this programmatically if at all possible. The code you shared should already be working on the DC side. Are you specifically looking for a similar solution on Cloud?

[elyashiv.grosser]

I want to avoid the mapping option, it’s irrelevant in our context.

And yes, I need something similar for cloud as well.
Thanks

[Majid]

Well, I wouldn’t consider it irrelevant as you can map the incoming value to the exact value present on the destination drop down, and then use this mapped value to get the correct option. It should work for sure, but yes, requires manual maintainance in case source or destination drop down values are changed or added/deleted.

Let me try to get this working on the cloud side via a script to do this dynamically though.

[Majid]

I quickly set up a custom text field called Source Field and a drop down select list on my Jira Cloud called Color. The Color drop down has the following options:

I used the following script on the Incoming on Jira Cloud:

httpClient.get("/rest/api/3/field/customfield_10105/context/10211/option").values.each {
    option ->
    if (option.value.toLowerCase() == replica.customFields."Source Field".value.toLowerCase())
      issue.customFields."Color".value = option.value
  }

I ran a GET call to this endpoint with the fieldId and contextId hardcoded in the call itself. Then iterated over the returned results and found which option actually matches the replica value, and once found, assign it.

Let me know if it works for you please.

Thanks
Majid

[francis]

Instead of using the httpClient, you can also use the ‘getOptions’ nodeHelper function

The benefit of using the nodeHelper functions is that Exalate will take into account API changes - making the sync script more robust.

(Not that that type of API doesn’t change a lot)

[elyashiv.grosser]

Hi @Majid
Thank you for the suggestion.
I think this API call is open for jira admins only, are you sure it will work when the exalate sync user doesn’t have admin privileges?

[elyashiv.grosser]

Hi @francis
Using getOptions was my first try as you can see in my initial message in the thread. But getOptions is for setting new content to the field and not for getting all the options for a field.
E.g. getOptions(issue,“emails”) won’t work.

[Majid]

Hey

Yes, it will work with the already authenticated proxy user. Please give it a shot.

Thanks
Majid

[elyashiv.grosser]

Hi @Majid
It seems to work.
I even shortened it like this:

httpClient.get(“/rest/api/3/field/customfield_1005/context/10211/option”).values.find {
if (it.value.equalsIgnoreCase(replica.customFields.“Source Field”.value))
issue.customFields.“Color”.value = it.value
}}

Will this work in jira on-prem as well?

[Majid]

Nice!
Glad to hear it worked. Please mark the answer as Solved so that it can benefit other readers.

And no, this will not work for onprem, but you already have a script for the onprem (that you shared initially), or am I missing something here.

Thanks
Majid

[elyashiv.grosser]

Hi @Majid
I want to have a similar solution for both instances, to make things simple.
If there isn’t an option, I will leave it.

[Majid]

Ye, I see your point, but both use different APIs. The helper method would be the way to unify this but as you said, that didnt work for you.

Thanks
Majid