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

Mandatory field in case of SLA breach

Robert P

Hi!

I have the following requirement: when the "time to resolution" SLA is breached the agent has to fill in a field (reason for the breach). This field is shown on the resolve issue screen and it has to be mandatory if the SLA got breached. Ideally, it should also only be shown in that case.

So far, I played arount with a ScriptRunner behaviour (no success) and a validator on the transistion (no success either as I couldn't import {{com.atlassian.servicedesk.api.sla.info.SlaInformationService}}).

I also stumbled across https://www.avisi.nl/blog/2016/02/15/jira-service-desk-tip-why-was-our-sla-breached but I would like to avoid introducing additional WF steps/transitions as we are using quite a lot of different WFs and that would mean a lot of additional efforts, also from a maintenance perspective.

As the mentioned article is from 2016 I hope there are better solutions in the meantime? I doubt this is a very "exotic" use case, is it?

Thanks,
Robert

Accepted answers

Thorsten Letschert _Decadis AG_

Hi @Robert P ,

unfortunately I can't help you with a custom script. However, if evaluating an additional app is applicable for you, a solution including Jira Workflow Toolbox is as easy as:

Adding a boolean validator
Use an expression as follows

count(issuesFromJQL("key = " + %{00015} + " AND 'your_SLA_name' = breached()")) = 1 IMPLIES %{12345} != null

The first part checks whether the current issue is returned when searching for the current issue key (field code 00015) as well as the SLA (your_SLA_name) being breached. The second part then results in the field with the field code 12345 being mandatory when the first part is true where 12345 has to be replaced with the field code of your 'reason for breach' custom field.

You could then conclude the configuration with a meaningfull error message to be displayed using the 'Message to show when validation fails' part.

Disclaimer: I am part of the team behind Jira Workflow Toolbox. Needless to say the app can be tested for free for 30 days as usual

Cheers
Thorsten

All comments

Rudy Holtkamp

If you do add another transition you can use the condition (as suggested in the article), but you also should add the reverse condition on the current transition. So in case you breached, you get to use the new transition with a transition screen that shows the breached reason field and the not-breach-transition will show the screen without the breached reason field.

I still think this is the way to go for you.

Robert P

Hi Rudy,

I agree that this will probably do the trick but as mentioned I'm seeking for a simpler, maybe even more elegant solution.

It's not only that we'd have to add all these additional transitions + validators but also the additional screen. For multiple environments.

Maybe Scriptrunner offers something I haven't discovered yet.

Hope dies last...

Rudy Holtkamp

Ok, here is a little hope...

You might want to make the mandatoriness of the field dependent on another field. (See also this thread.)

Before you can do that you have to make another custom field, like 'breached'. Which you need to set when the issue is breached. For which you need to query on intervals to be able to set the field. (Which might impact the Jira performance, depending on how many JSD tickets you will have and how often you want to run the query.)

... like I said a little hope.

Robert P

... which died with "might impact Jira's performance" :-(

I should have mentioned that probably - we are talking about quite a lot of tickets and performance is obviously a key issue...

Thorsten Letschert _Decadis AG_

Hi @Robert P ,

unfortunately I can't help you with a custom script. However, if evaluating an additional app is applicable for you, a solution including Jira Workflow Toolbox is as easy as:

Adding a boolean validator
Use an expression as follows

count(issuesFromJQL("key = " + %{00015} + " AND 'your_SLA_name' = breached()")) = 1 IMPLIES %{12345} != null

You could then conclude the configuration with a meaningfull error message to be displayed using the 'Message to show when validation fails' part.

Disclaimer: I am part of the team behind Jira Workflow Toolbox. Needless to say the app can be tested for free for 30 days as usual

Cheers
Thorsten

Thorsten Letschert _Decadis AG_

Hi @Robert P ,

thanks to my attentive colleague @Max Foerster - K15t who takes his role as a community champion very seriously, I've been looking for a behaviour related solution once again and came up with the following:

import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.search.SearchException
import com.atlassian.jira.web.bean.PagerFilter

import com.onresolve.jira.groovy.user.FieldBehaviours
import groovy.transform.BaseScript

@BaseScript FieldBehaviours fieldBehaviours

if (getAction()?.id == 951) { 

def targetField = getFieldById("yourField")
def key = underlyingIssue?.getKey()

final String jqlSearch = "key = " + key + " AND 'your_SLA_name' = breached()" // the jql query you want to search with

def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def searchService = ComponentAccessor.getComponentOfType(SearchService)
SearchService.ParseResult parseResult = searchService.parseQuery(user, jqlSearch)

if (parseResult.isValid()) {
try {
def results = searchService.search(user, parseResult.query, PagerFilter.unlimitedFilter)
def issues = results.results
if (issues.size() != 0) {
log.warn("Valid query: " + jqlSearch + " - " + issues.size())
targetField.setRequired(true);
}
} catch (SearchException e) {
e.printStackTrace()
}
} else {
log.warn("Invalid query: " + jqlSearch)
return null
}
}

I've added this one as an initialiser, so please update the action ID 951 to the one applicable for you (the transition id where you want this initialiser to be loaded). While there might be a more elegant way, this approach is doing the trick for me.

Cheers
Thorsten

Robert P

Thanks a lot, Thorsten - I will give it a try asap and let you know if it worked for me.

Best,
Robert

Thorsten Letschert _Decadis AG_

Hi @Robert P ,

have you been successful?

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