How do I get current Customer Request Type in Behaviours?

Szymon Trocha November 9, 2022

Hi all,

I'm trying to build an Initializer script in Behaviours. I have one behaviour for different Customer Reuqest Types. What I want to get is that when issue is created (both by an agent and from user portal) depending on the Customer Request Type some fields are hidden in the initiallly loaded Create issue window.

I'm having troubles in fetching the current value of Customer Reuqest Type field for both the agent and when user creates via portal. So far I have the current code based on a mixture of some found code:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.servicedesk.api.requesttype.RequestTypeService
import com.onresolve.scriptrunner.runner.customisers.PluginModule
import com.onresolve.scriptrunner.runner.customisers.WithPlugin

@WithPlugin("com.atlassian.servicedesk")
@PluginModule
RequestTypeService requestTypeService

def issue = event.issue
def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def customFieldManager = ComponentAccessor.customFieldManager
def requestTypeCustomField = customFieldManager.getCustomFieldObjects(issue).findByName('Customer Request Type')
log.warn("log-behaviour-hide-fields-colocation INITIALIZE customField value: " + customField)

but I'm stucked at this stage. The Scriptrunner checker print error "[Static type checking] - Cannot find matching method com.atlassian.jira.issue.CustomFieldManager#getCustomFieldObjects(java.lang.Object). Please check if the declared type is correct and if the method exists." so even doesn't allow me to proceed further.

Hod do I properly retrieve the current value of Customer Request Type when creating an issue?

I'm using Jira Software 8.22.4, Jira Service Management 4.22.4 and ScriptRunner v. 6.53

Thank you in advance

2 answers

1 accepted

3 votes
Answer accepted
Peter-Dave Sheehan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 9, 2022

Hi @Szymon Trocha  I have 4 observations about your question.

First, "Static Type Checking Errors" do not necessarily show stoppers.

Groovy by design can be dynamically typed or strongly typed. The downside of relying on dynamic typing is the occasional inability of some parsers to detect the correct type inference to validate the syntax.
In many cases, the code will run just fine. 

Second, I see "event.issue" in your script... so this looks like you copied it from a Scripted Event Listener. That won't work out of the box for a behaviour. Also, in a behaviour, especially one triggered during issue creation, there will be no issue object available. So issue.getCustomFieldValue(customField) will not be an option. You need to use behaviour methods.

Third, when a behaviour is called from the portal, you will have access to "getRequestTypeName()" as a built-in method in your script. You should use that if it's available as the first option. Only fall back to the more complex code if you absolutely have to.

Fourth, the value for the Customer Request Type will yield a "key" that looks like "abc/c18c3b9c-aceb-4c8b-9e9c-d40c9c17ee02". Not terribly useful for performing some logic. I see you were on the right track with requestTypeService.

Putting all that together, I propose this:

import com.atlassian.servicedesk.api.ServiceDeskManager
import com.atlassian.servicedesk.api.requesttype.RequestTypeService
import com.onresolve.jira.groovy.user.FieldBehaviours
import com.onresolve.scriptrunner.runner.customisers.PluginModule
import com.onresolve.scriptrunner.runner.customisers.WithPlugin
import groovy.transform.BaseScript

@WithPlugin("com.atlassian.servicedesk") //allows you to import com.atlassin.servicedesk
@BaseScript FieldBehaviours fieldBehaviours //not needed if you store your script in-line, but helpful when using in script editor or in an external IDE
@PluginModule RequestTypeService requestTypeService
@PluginModule ServiceDeskManager serviceDeskManager

def requestTypeName = getRequestTypeName()
if (!requestTypeName) {
def custerRequestTypeFormField = getFieldByName('Customer Request Type')
String requestTypeKey = custerRequestTypeFormField.value
if (!requestTypeKey) {
log.error "No customer request type has been detected. This behaviour can't function"
return
}
def sd = serviceDeskManager.getServiceDeskForProject(issueContext.projectObject)
def queryBuilder = requestTypeService.newQueryBuilder()
queryBuilder.requestOverrideSecurity(true)
queryBuilder.serviceDesk(sd.id)
def allRequestTypes = requestTypeService.getRequestTypes(null, queryBuilder.build()).results
def requestType = allRequestTypes.find {
log.debug "$it.properties.key (${requestTypeKey.contains(it.properties.key as String)})"
requestTypeKey.contains(it.properties.key as String)
}
if (!requestType) {
log.error "No Request Type matching the key present in Customer Request Type ($requestTypeKey) can be found in $issueContext.projectObject.key. This behaviour can't function"
return
}
requestTypeName = requestType.name
}

def requestTypeFieldsToHide = [
"requestTYpe1": ['fieldA', 'fieldb', 'fieldc'],
"requestTYpe2": ['fieldC', 'fieldD', 'fieldE']
]

requestTypeFieldsToHide[requestTypeName].each { fieldName ->
getFieldByName(fieldName).setHidden(true)
}
Szymon Trocha November 10, 2022

Hi @Peter-Dave Sheehan Perfect suggestion - works like a charm for my scenario of differentating between customer portal and gaent!! Thank you very much also for additional explanations.

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2024

Hi @Peter-Dave Sheehan 

Thanks for the explanation. I do have a question, in case if we change request type after choosing one(if we chose wrong request type by mistake), the fields still remains hidden. 

Is there a way to check that, if I chose req type 1 the fields gets hidden(correct behavior), but I decide to chose req type 2, the field should be not hidden. Thanks for the help. 


Peter-Dave Sheehan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2024

The original question was talking about an Initialiser script.

If you want to react to changes to the customer request type field on the Jira (not portal) side, then you need to add that field to the behaviour configuration and add a server-side script to react to that change and show/hide the fields as necessary.

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2024

Hi @Peter-Dave Sheehan 

Thanks for the update, I realized it later after posting the comment, and hence it is working.


Although another concern that I questioned, since we hide some request type (based on issue type) in/from the portal which we don't want customer to see. But when we add 'Customer Request type' field in Create Screen (Jira Side), the field displays all the Customer Request type which is hidden from portal when we select a particular issue type. Is there a way to hide Customer Request Type based on issue type from the JIRA side as well via behavior?

Thank you for the help in advance. If you want I can raise a separate question as well :)

Peter-Dave Sheehan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2024

I've never tried to manipulate the options in the Customer Request Type field.

But if it's possible, it will employe a mechanism similar to this: https://docs.adaptavist.com/sr4js/latest/features/behaviours/behaviours-examples/restricting-issue-types

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2024

Hi @Peter-Dave Sheehan 

Thanks for the update, will try using the above logic for the customer request type and if it works will update you. 

Thank you. 

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 17, 2024

Hi @Peter-Dave Sheehan 

I tried using the logic as above, but no luck. Can you please help with this. Would appreciate it.

I want manipulate the option in customer request wrt Issue type.

Thank you.

Peter-Dave Sheehan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 18, 2024

Upon doing a bit of testing, I don't think that this is currently supported. You can raise a feature request with adaptavist.

In the meantime, I suggest you use behaviours to validate the selection rather than hiding it.

Here is a sample script you can add to your "Customer Request Type" in a behaviour with "project/issue type mapping".

import com.atlassian.servicedesk.internal.customfields.origin.VpOrigin
import com.onresolve.scriptrunner.runner.customisers.WithPlugin
@WithPlugin("com.atlassian.servicedesk") sdPlugin

def crtFld = getFieldById(fieldChanged)
crtFld.clearError()
if(underlyingIssue) return //do nothing when there is an underlying issue, this means we're editing the issue
if(requestTypeName) return //do nothing if this happens to be called from the portal
//you may need to output to log (or use setHelpText) to find your keys
def allowedRequestTypeKeys = ['00c801e5-9279-4604-9769-b25b96d2dc60']
if(!allowedRequestTypeKeys.contains((crtFld.value as VpOrigin)?.requestTypeKey)){
crtFld.setError("This request type is not valid from the Agent view. Select a different request type or raise this issue from the portal.")
}
Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 18, 2024

Hi @Peter-Dave Sheehan 

thanks for the guidance. I will raise the request and until then I’ll test this piece of code, which will also partially clear my problem. Will update you once tested.

Regards

0 votes
Joseph Chung Yin
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 9, 2022

@Szymon Trocha -

Take a look at the following...  Hope this helps.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue;

def customFieldManager = ComponentAccessor.getCustomFieldManager()
def optionsManager = ComponentAccessor.getOptionsManager()

def customerRequestCf = customFieldManager.getCustomFieldObjectsByName("Customer Request Type")
def customerReq = issue.getCustomFieldValue(customerRequestCf)

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 17, 2024

Hi @Joseph Chung Yin 

Unfortunately this is not working. Is there a way to customer request type options based on issue type, via behavior.
For example - if I issue type = 'incident', I only want request type A and B to be visible, not other requests of incident type.

I tried using the similar mechanism, given - https://docs.adaptavist.com/sr4js/latest/features/behaviours/behaviours-examples/restricting-issue-types

but it did not work, will it possible for you to help with this. I am using Jira Server 

Thank you.

Joseph Chung Yin
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 18, 2024

@Harsh -

What do you mean by "if I issue type = 'incident', I only want request type A and B to be visible, not other requests of incident type."?  Please clarify what exactly you want to accomplish using Behavior in your env?

Best, Joseph

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 18, 2024

Hi @Joseph Chung Yin 

I want to restrict customer request type based on the issue type when agent create ticket from Jira view and not the portal, using behaviour.

Ex - the agent chooses issue type= task, then the field customer request type should show only request A in the list and not request B. Both the request A and B is associated with Task issue type. 

Hope this helps. 

Joseph Chung Yin
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 18, 2024

@Harsh -

When you mentioned "users" are you referring to customers, if so, they should be creating issues via the portal UI.  In the portal UI, you can just hide the request types from the users that you don't want them to create issue from them.

At this time, there is a current enhancement request for the ability to control request type issue creation on the Atlassian side  https://jira.atlassian.com/browse/JSDCLOUD-195

I would recommend for you review it and add yourself as a watcher, so you can be updated when Atlassian provides more information.

At this time, I don't understand why you are over complicating the issue by trying to use Behavior to accomplish the need.

Best, Joseph

Harsh
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 19, 2024

Hi @Joseph Chung Yin 

I am aware that we can hide the request from the portal UI, which is already in place.

But I need to achieve the following from the agent side (project/issue type mapping) based on the issue type. 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events