I need to invoke a groovy script when a user tries to view a jira issue or on click of edit button for a jira Issue?

[rahuldanwade]

Hi naganathan

To do this

1.Write your listener as groovy - but as a groovy class, not a groovy script. You could just extend AbstractIssueEventListener, but your class merely needs to respond to workflowEvent(IssueEvent).

2.Copy the .groovy file to the correct place under the classes directory (depending on directorystructure)                                                                                                                                                                     JIRA\atlassian-jira\WEB-INF\classes\com\<yourfoldername>\example.groovy

JIRA_INSTALLATION_DIRECTORY\atlassian-jira\WEB-INF\classes\com\<yourfoldername>\example.groovy

3.Go to Script Listeners, and enter the fullt qualifid name of your class

e.g. com.oneditissue.jira.groovy.listeners.ExampleListener

[Chris Solgat]

You only need to have a listener if you want it to do something on it's own, like update a field if the issue hasn't been updated after x days. Otherwise if you just need it to be updated when the issue is viewed or edited, it can just be a scripted field. You can put the code for a scripted field directly into the field, or you can store it on the server. If you have a newer version of scriptrunner, there is actually a "scripts" directory in the Home (runtime) directory. That way you can modify the script as needed without having to restart the JVM every time you modify it.

[Chris Solgat]

A scripted field would work best.  A scripted field will trigger every time the issue is viewed.  It is very wise to create a context for the field that is scoped down to only the project(s) that need to use it.  As your JIRA Instance grows, scripted fields will cause your re-indexes to take significantly longer, as well as consuming large amounts of CPU and Memory.  We have an instance that uses about 15 scripted fields and has about 500,000 issues.  Depending on the number of CPU's available, the re-index process was taking between 4 hours (24 cores) and 10 hours (6 cores).  As soon as we turn off scripted fields the re-index will complete between 1 and 1.5 hours.

[Deleted user]

I did not know that scripted fields eat that much CPU and Memory. One of my JIRA instance is 580,000~ , 1,200~ Projects. The server it's running on has 32 processor cores and 256 gigabytes of RAM. Shared storage for each cluster is over 10 terabytes of tier one SAN. The indexing took a minimum of 4 hours. I only created 1 scripted field.

[Chris Solgat]

What we found to be the biggest culprit was the multithreading. For each issue, the script would run, creating a new thread. Since during a locked re-index, I believe it tries to do them in batches of 1,000 issues, each issue has to wait inline for it's thread to be picked up by the processors. We found this out because we went from a physical server with the specs above to a virtual server with only 6 cores. The hardware was figured to be about 3 generations newer so we were expecting to see a huge improvement in performance. For the most part we did, except for the re-indexing process. We went from the re-index taking 4 hours on the old hardware to it taking nearly 10 hrs on the new hardware. After a lot of digging trying to find out why this was performing slower, we finally narrowed it down to the scripted fields.