Issue creation using Issue factory method

[IT]

Hi,

I'm using below script to create issue while running script in script field it is taking too long  to create and high load on server as well .

import com.atlassian.jira.issue.MutableIssue

import com.atlassian.jira.component.ComponentAccessor

 // Get necessary components

def issueFactory = ComponentAccessor.getIssueFactory()

def issueManager = ComponentAccessor.getIssueManager()

 // Accept external values for issue fields

def projectKey = "TEST" 

def issueTypeId = "101" 

def summary = "Summary"  

def description = "DESCRIPTION"  

// Get the project object

def project = ComponentAccessor.getProjectManager().getProjectObjByKey(projectKey)

// Create the issue object

MutableIssue newIssue = issueFactory.getIssue()

newIssue.setProjectObject(project)

newIssue.setIssueTypeId(issueTypeId)

newIssue.setSummary(summary)

newIssue.setDescription(description)

// Get the logged-in user

def currentUser= ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()

//Create issue

    def newIssueCreated = issueManager.createIssueObject(currentUser, newIssue)

[Nic Brough -Adaptavist- · Accepted solution]

Um, you say "create issue while running script in script field"

Is that really what you are doing?   If it is, then that is the reason your code isn't working - it is an insane thing to do.

Edit: I am sorry, "insane" is an unfair word to use.  I apologise for that.

It is however, accurate, once you hear how scripted fields work, and what they are for.  I cannot think of any good reason you would try to create issues in a scripted field.  (Using data calculated by one to spawn more issues, quite possibly, but not during the calculation)

[Tuncay Senturk _Snapbytes_]

Ahaha! You're absolutely right. It seems I was so excited to dive into the code that I completely overlooked the fact that it was a script field.

[Nic Brough -Adaptavist-]

Yeah, it's a "fun" one.  

One thing I didn't mention - scripts for scripted fields often run twice in some places.  If you stick some "log that this script ran into atlassian-jira.log" and then have a wander through some searching, reporting, dashboarding, viewing, editing and transitioning an issue that has a scripted field, you'll see one action can trigger the script to run 1 or 2 times.  I've seen some that will log it 4 times!

The reason I suspect the performance is because:

1. Scripted field script runs
2. Issue starts to get created
3. As part of the issue, the scripted field script runs again
4. Which starts to create a new issue

The process then goes into a loop as process 4 is the same thing as process 2.  The loop may never complete the nested work.  So it justs sits there chewing up memory and CPU time until one of the threads dies or errors, or part of the code creates an issue that does not have the scripted field on it.

FWIW, the code isn't particularly wrong, it's just in the wrong place.  Yours is better, but it would be remiss of me not to point out that later versions of Scriptrunner have HAPI (I like to explain that as "Helpful API", although we still have not settled on a formal name!)

The HAPI version of "create an issue" needs no imports, and the simplest example is:

Issues.create('ABC', 'Task') {

    setSummary('my first HAPI 😍')

}

[Tuncay Senturk _Snapbytes_]

You are right. I noticed that the 'getValueFromIssue' method may be invoked 12 times within a single request. From my research Editing an issue was triggering the most calls to this method. My observations were based on tests using Jira 8.4, but I'm not sure if there have been any enhancements since then. This reminds me of a post I read about a decade ago."

[Nic Brough -Adaptavist-]

I think I remember first running into this a few weeks after upgrading our Scriptrunner to a version that first implemented scripted fields

Yes, I'm that long-in-the-tooth, I started using SR when Jamie Echlin explained to me (probably on the old Jive fora that I think of as "3 versions of community before now" which was a long time before either of us joined Adaptavist), that I could stop writing 600 lines of code and compile it into a plugin with some very limited options and have to rewrite on most requests for change, and start writing just the code that actually did something in the post-function/Validator/condition.  I found some of my old work on an old hard-disk over the winter break and one of them is a brilliant example of evolution.

• 600(ish) lines of code for the plugin, forcing a whole development cycle for any change.
• 12 lines of code to do it in Scriptrunner for Jira 3.something and similar for later versions, so a change was 2 minutes, testing maybe 20.
• 1 line in HAPI now.

[Tuncay Senturk _Snapbytes_ · Accepted solution]

I did not see anything wrong in your code that will cause performance and high CPU load problems. However, I'd suggest creating issue using the issueService.

import com.atlassian.jira.bc.issue.IssueService 

// Create a new issue
IssueService.CreateValidationResult createValidationResult = issueService.validateCreate(
    currentUser,
    new IssueService.IssueBuilder()
       .project(project)
       .issueTypeId(issueTypeId)
       .summary(summary)
       .description(description)
       .build()
)

if (createValidationResult.isValid()) {
   IssueService.IssueResult createResult = issueService.create(currentUser, createValidationResult)
   if (createResult.isValid()) {
      MutableIssue newIssue = createResult.getIssue()
      log.info "Issue created successfully: ${newIssue.getKey()}"
   } else {
      log.info "Error creating issue: ${createResult.getErrorCollection()}"
   }
} else {
   log.info "Error validating issue: ${createValidationResult.getErrorCollection()}"
}

If you are sure that it causes performance issues, you can add more logs to see which line took how many milliseconds.