When wanting to perform validations on issue, but requiring different scenarios based on the request type we needed to get the determine the request type of the new issue and perform the necessary checks.
A few question out there which get the name for issues that have already been created, a new issue does not get a Key prior to being created.
Was able to get the Request Type Id from the issue, but working between DEV, TES and PROD environments it becomes difficult to manage and keep in sync.
So with some reading and testing i came up with the following method / function.
import com.atlassian.jira.issue.Issue
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
import com.atlassian.servicedesk.internal.customfields.origin.VpOrigin
import com.atlassian.servicedesk.internal.feature.customer.request.requesttype.CachedImmutableRequestTypeImpl
String getRequestTypeName(Issue i){ // Get the Name of the Request Type.
@WithPlugin("com.atlassian.servicedesk")
@PluginModule
RequestTypeService requestTypeService
def customFieldManager = ComponentAccessor.customFieldManager
def requestTypeCustomField = customFieldManager.getCustomFieldObjects(i).findByName('Customer Request Type')
def requestTypeKey = (i.getCustomFieldValue(requestTypeCustomField) as VpOrigin)?.requestTypeKey
if (!requestTypeKey) {
return
}
def query = requestTypeService.newQueryBuilder().serviceDesk(15).build()
def requestType = requestTypeService.getRequestTypes(Users.getLoggedInUser(), query).results.find {
(it as CachedImmutableRequestTypeImpl).key == requestTypeKey
}
return requestType.name
}
The query filters on the service desk Id.
15 in the above script, but you would need to change this for your own.
Hi David,
Instead of relying on the Request Type ID, which can differ across environments, you can use the Request Type Name. Request Type Names are generally consistent across environments, making them a better candidate for validation logic.
Here’s a sample method/function you could use:
When an issue is created, you can retrieve the Request Type Name instead of the ID. This can be done by accessing the issue's fields or using an API call if necessary.
Create a mapping between Request Type Names and the corresponding validations. This way, you can dynamically perform different checks based on the Request Type Name. For example:
def get_validation_for_request_type(request_type_name):
validation_mapping = {
"Bug Report": validate_bug_report,
"Feature Request": validate_feature_request,
"Support Request": validate_support_request,
# Add more mappings as necessary
}
return validation_mapping.get(request_type_name, default_validation)
def validate_bug_report(issue):
# Perform specific validation for bug reports
pass
def validate_feature_request(issue):
# Perform specific validation for feature requests
pass
def validate_support_request(issue):
# Perform specific validation for support requests
pass
def default_validation(issue):
# Default validation if no specific type is matched
pass
# Usage
request_type_name = get_request_type_name(issue) # This function should retrieve the request type name from the issue
validation_function = get_validation_for_request_type(request_type_name)
validation_function(issue)
Since Request Type Names are consistent, you don't have to worry about different environments. The same logic should work across DEV, TES, and PROD without modification.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I posted my own answer after not finding a solution on here and working it out for myself.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.