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

[Thorsten Letschert _Decadis AG_ · Accepted solution]

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

[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?

[Robert P]

Hi @Thorsten Letschert _Decadis AG_ ,

sorry for the delay. I just gave it a quick try and it actually seems to work pretty well. I'll have to do some more test, but it really looks promising so far. :)

The only thing I changed, was to replace "def targetField = getFieldById(...)" by "def targetField = getFieldByName(...)" as I wasn't able to quickly figure out what ID would be expected ("cf[12345]" didn't work).

Thanks again for all your help!

Best,
Robert

[Thorsten Letschert _Decadis AG_]

Hey @Robert P ,

Thanks for the feedback - you're always welcome.

For future reference using the ID should work as follows:

getFieldById("customfield_12345")

Cheers
Thorsten 

[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...

[Rudy Holtkamp]

Then Thorsten might be on to something, but I'm out of ideas.