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

Different screens for Jira Service Desk Request Types?

Chrisjir Parkin

Realizing that one can only modify Request Type if the underlying Issue Type doesn't change, we resorted to having a single Issue Type for our Service Desk project. This allows us to use Automation rules to move customer tickets between Request Types as needed.

We also found out that we can make conditional workflow transitions for each different Request Type. The method is somewhat of a workaround, but, above all, it works. Having created Issues of the various Request Types, we use ScriptRunner Console to obtain the Option ID of a the specific Request Type required in the condition. The Option ID looks like this, where <project key> is replaced by the project key for your project

<project key>/1f209352-fd6e-42db-9fe5-47d405a0f7ed

Then we add a Workflow Condition that compares the field "Customer Request Type" to our result and select the option to compare using Option ID rather than String.

JSD is good about letting us specify which fields appear on the portal for each request type. So, we can have the customer see only those fields that pertain to their area of interest. After that, though, and since we have multiple request types mapped to one Issue Type, we have only one Issue Type Screen Scheme. So, when it comes time to View or Edit the issue, we must display all the fields associated with the Issue Type. This crowds the screen with lots of irrelevant fields.

Imagine two Request Types (Purchase and Human Resources) mapped to a single Issue Type (Request). Let us also say that we use Edit Fields on the Request Type to specify Position Name, Supervisor and Length of Term for the Human Resources request type. Likewise, we use the custom fields Total Cost, Shipping Address and Budget Number for the Purchase Request Type. So far, so good.

After the Issue is created, from within JSD as we Edit or View the ticket, we have only a single Screen by which to see it. The Edit and View screen shows all the fields: Position Name, Supervisor and Length of Term as well as the purchase fields.

Has anyone found a way to use a Screen based on Request Type rather than Issue Type? What we're looking for is, in effect, a Screen Scheme based on Request Type instead of Issue Type.

Accepted answers

Andrew Laden

You can also use the "Live Fields" functionality of Power Scripts for Jira to show/hide fields depending on other settings. Similar functionality to behaviors for scriptrunner but the syntax of the language is a little easier.

Another option is to do all your edits in transitions. Make a transition screen for each request type. Then create a looping transition (from any to itself) with a condition based on the request type, so that only 1 is valid at any time. The users will select an edit transition, and the transition screen will pop up specific to that request type.

To enforce this, you want the edit screen in your screen scheme to be empty, or at a minimum only contain the fields that are valid for all issues. THose will be the only ones you will be allowed to edit "in-line"

Don't worry about the view screen. If the custom field is empty, it wont show up on there regardless.

All comments

Bastian Stehmann

Hi @Chrisjir Parkin ,

If you want a screen scheme, there is no way to do it without different issue types.

But as you are already using Scriptrunner, you may achieve what you want by using the behaviour part of this.

Never tried to build it the way you did,but it should be possible to show or hide the fields depending on other issue fields.

But I don't think that it will be good to maintain and administer, so you should think well about it.

Chrisjir Parkin

I understand. Thanks for responding. I'm still hoping to find a solution.

On the one hand, if I create a one-to-one correspondence between Issue Types and Request Types, I can have Issue Type Screen Schemes, with different screens for different request types, which makes for an organized visual presentation, but I can't use Automation to change Request Types. Request Type can only change if the underlying Issue Type remains the same.

On the other hand, if I map all my Request Types to a single Issue Type, I can use Automation and change Request Types, but there's no Issue Type Screen Scheme.

Having to choose between these two alternatives prompts me to ask if there's a 3rd alternative, something that Atlassian or its business partners know about, that would be just what I need. Ultimately, I want to use Automation to assign request types, and still have screen schemes that pertain to the specific request so as to limit the visibility of irrelevant fields. That's the goal. I would be happy to use different Issue Types, if I could still use Automation to change between Request Type in the Workflow.

Andrew Laden

Don't worry about the view screen. If the custom field is empty, it wont show up on there regardless.

Chrisjir Parkin

Using the recursive Transition Screen will probably satisfy the requirement. Most of the time, people should just approve and/or transition the ticket to the next status. Having a makeshift Edit Screen will most likely suffice. Thanks.

David Cahill_lu8y1n

I'm amazed at the solutions people come up with for things that should be built in lol.

Welcome!

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

Quick Links

Find more posts tagged with

server

jira-service-desk

jira-service-desk-server

request-type

screen

screen-scheme