Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

script listener to service edit Edited

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")
}
}

1 answer

1 accepted

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

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

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

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 

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

Hi Daniel

 

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

 

Many thanks

 

Tyler

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase

All you wanted to know about customer support KPIs

When working in customer support, it’s crucial to calculate, analyze and monitor specific numbers, called KPIs (Key Performance Indicators). They go hand-in-hand with customer satisfaction, problem d...

6 views 0 1
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you