script listener to service edit

[Tyler Brown-Jones]

Hi

i need to change this current script listener in to a service to execute once a day.

I understand how to set the service up etc but i realised my code doesn't actually get all issues from all projects, it only gets the issue that triggered the listener.

I need to change my code to get all projects and all issues within the projects to check if they have an estimate, i hope you can help as i will need to integrate this in to a lot more of my other reporting scripts. Thanks in advanced!

import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.CustomFieldManager;
import java.util.logging.Logger
import com.atlassian.mail.Email
import com.atlassian.mail.server.MailServerManager
import com.atlassian.mail.server.SMTPMailServer
import com.atlassian.jira.component.ComponentAccessor
import org.apache.log4j.Category

def Category log = Category.getInstance("com.onresolve.jira.groovy")
log.setLevel(org.apache.log4j.Level.DEBUG)
log.debug("start of code")

def estField = ComponentAccessor.getCustomFieldManager().getCustomFieldObject(11401)
def cFieldValue = issue.getCustomFieldValue(estField)
log.debug(cFieldValue)
Issue issue = event.issue

if ( cFieldValue == 0.0) {
 def subject = "${issue.key} has no Estimate"
 def body = "https://test.atlassian.net/issue/${issue.key} \n This issue does not have an estimate"
 def emailAddr = "test@test.com"
 SMTPMailServer mailServer = ComponentAccessor.getMailServerManager().getDefaultSMTPMailServer()

 if (mailServer) {
 Email email = new Email(emailAddr);
 email.setSubject(subject);
 email.setBody(body.toString());
 mailServer.send(email);
 log.debug("Mail sent")
 } 
 else {
 log.debug("Please make sure that a valid mailServer is configured") 
 }
}

[Daniel Yelamos [Adaptavist] · Accepted solution]

Hi Tyler.

This is a rather dangerous concept. 
Selecting all of your issues within all of your projects is a very very processing heavy move, it will of course vary depending on the size of your instance, but I've seen scripts like these resulting into support tickets for Adaptavist. 

Could you please explain what is is exactly that you want done? Maybe there is a way of narrowing down your search.

Cheers!

Dyelamos

[Tyler Brown-Jones]

Hi Daniel - really appreciate the feedback.

I thought that may have been the case but wanted to put the question out there anyhow. 

The end point that I want is for all my reporting scripts to be ran on a service to be executed once a day. These consist of checking if an issue has an estimate, Checking if an issue has time allocated to it but isn't in an active sprint and different ones related to reporting like these -  they all send emails if the report's condition's are met.

This means that all issues need to have these reports ran on, but only a few will actually have the mail part executed on. 

If you are able to provide a better approach to do this, that would be extremely helpful and greatly appreciated. 

Many thanks

Tyler

[Daniel Yelamos [Adaptavist]]

Hi Tyler.

In my most modest opinion(I mean that 100%), regarding this part of your post:

"These consist of checking if an issue has an estimate, Checking if an issue has time allocated to it but isn't in an active sprint and different ones related to reporting like these -  they all send emails if the report's condition's are met."

I think that you should have a more complex workflow to meet your reporting needs. Checking all of these conditions in bulk takes a lot of time. Because you need to collect these records and perform complex conditions.

If you had a field that marks the state of an issue, for example(this doesn't need to be the status field, but it could be) this would be a lot easier. Imagine the next scenario:

If an issue has an estimate, it's automatically transitioned to a state "development estimated" or for example, a hidden field of yours, "development estimated" gets set to true. 

This way you would save a lot of the problems that you have, cause you could collect these by status, or by "field = true" which is a much less complex query.

The problem isn't dealing with all of your issues, that JIRA is prepared to do, the problem is a single groovy thread having to parse and perform condition processing code in all of the issues in your instance in a small time period. 

Divide and conquer! 

There could be other opinions out there, but this is mine :) Take it with a grain of salt though, I could be wrong.

Cheers

Dyelamos

[Tyler Brown-Jones]

That is a very interesting approach and one i am open to implementing, my only thought on this is, will this not be checking for conditions across all issues to see if the state is == to "development estimated" or if the field is set to true? Will this still not present the same issue with the bulk parsing and condition processing on the single groovy thread?

If i'm misunderstanding your suggestion could you please advise

Much appreciated and a big thanks!

Tyler 

[Daniel Yelamos [Adaptavist]]

Hi Tyler.

I'm not saying my way is better than yours, it isn't the action that concerns me, it is the initial search and then performing your search within a very big subset. If you do it your way:

1. Collect all of the issues of every project in your instance. <- These are a lot of issues and a very general search.

2. Go through them one by one checking your condition.  <- This is the heavy part.

3. Collect your set, post the emails.

Now think about what you need to do with a type:

1. Collect all of the issues in one particular status in JQL based on a simple condition. Something like: "affectedVersion = 5.1.9" or in your case "status = estimated placed" or "estimatedPlaced = true"

2. Send your emails there.

Now you have moved the second part into the collection of issues, saving a lot of time with a simple action. 

Does this make sense?

Cheers

Dyelamos

[Tyler Brown-Jones]

Hi Daniel

That makes a lot of sense now thank you! I will implement this and see how it goes.

Many thanks

Tyler