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; } } }

Condition with Request Type on workflow transition

unknown

I am using a workflow with a transition from status 'Verzoek' (request) to 'In Behandeling' (In progress). I add a condition to this transition called 'The field Request Type will have to be equal to value 'Algemene vraag'. Compared as String.'

After this It is not possible to perform this transition on an issue which meets this condition.

What could be wrong here?

Accepted answers

All comments

Nadir MEZIANI

Hi,

could you tell what did you do to compare this value, plugin scripting or other ?

unknown

He Zezeto,

I'm not sure what you mean. I'm just configuring the regular Jira workflow. Using Jira Cloud.

No plugins, scripting or whatever.

Jens_kc01vr

The problem is likely that you're comparing with the visible value of the request type. But you need to compare with the internal value Jira actually stores. I had a similar case where I wanted to condition to make it not possible to resolve an issue when the request type was set to the value "Undefined". I had to configure the condition to compare with this string

gi/6961fa42-b43c-4b7b-821c-0be4f008ac5a

instead of the word Undefined.

I found this value by exporting an issue with the desired request type to CSV. Due to the way Jira Service Desk is kludged onto Jira, the JSD custom fields aren't exported properly and thus exposes the internal identifiers.

Patricia Francezi_iDev_

Hi @Jens can you help me?

I have the same problem, found my request type ID, but i have tried comparing with string and Option ID, and still does not work as intended.

the difference from your cenario is that Im comparing != Request by Email

any clue?

Jens_kc01vr

Hi Patricia

I don't really know. My only suggestion is that it may be something related to quotes maybe?

PhilSpo

https://your-domain.atlassian.net/rest/servicedesk/1/servicedesk/request/10071/request-types

(Where 10071 is the value for a specific issue type)

brings back all the relevant request types for that issue type:

avatarType=SD_REQTYPE&avatarId=10508","issueType":10011,"issueTypeIconUrl":"/secure/viewavatar?size=medium&avatarId=10558&avatarType=issuetype","createScreenId":0,"viewScreenId":0,"issueTypeName":"Support","name":"Urgent Out of Hours Voicemail","description":"Out of hours urgent voicemail received","descriptionHtml":"<p>Out of hours urgent voicemail received</p>","helpText":"","helpTextHtml":"","order":0,"usedByEmailSettings":false,"groups":[],"practices":[]},{"id":42,"cvId":5,"portalKey":"ccs","portalId":5,"key":"1ea9d869-77e8-4576-ae55-ae6fdfed451e","icon":10493,"iconUrl"

I found out that the OptionID is made up of two separate parts concatenated together: portalKey/key

So from the above example I used 'ccs/1ea9d869-77e8-4576-ae55-ae6fdfed451e'

As you can see below, its not very intuitive for yourself or anyone else to know what's going on if they ever need to edit the transition conditions. I will have to make a note of which key is which request type.

Luis Felipe Studzinski Santos

This is a great tip. Thank you very much,

Welcome!

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

Quick Links

Find more posts tagged with

jira