Groovy Post Function -- best way to get all populated fields (system and custom) for an issue?

[Bryan Karsh]

I'm looking for the best way to grab all populated fields for an issue (both system and custom) in a groovy post-function (which will then be passed on to some other scripts for some automated tasks). Below is a way I was able to do it, but I fear that I am using non-standard or deprecated means to go about it. Can someone take a look, and let me know if it looks good?

import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.IssueManager
import com.atlassian.jira.issue.Issue

IssueManager issueManager = ComponentManager.getInstance().getIssueManager()
CustomFieldManager customFieldManager = ComponentManager.getInstance().getCustomFieldManager()


myissue = issue.key

Issue issue = issueManager.getIssueObject( "$myissue" )

def cflist = customFieldManager.getCustomFieldObjects(issue)

def map = new HashMap<String,String>()

cflist.each {cf ->
Object value = issue.getCustomFieldValue(cf)
if(value){
    map << [(cf):"$value"]
}
}

def systemfields = issueManager.getIssue("$issue")  //using GenericObject since it seems to contain issue fields -- appreciate alternative suggestions

def iterator = systemfields.entrySet().iterator()

while (iterator.hasNext()) {

  if (! iterator.next().value) {
    iterator.remove()
  }
}


map << systemfields

def body = map.collect { k, v -> "${k}^^${v}" }.join('::')

[JamieA · Accepted solution]

I'd say why do you want to do this?

Having said that, what you're doing doesn't seem too outlandish. You don't have to use the GenericValue but then you do need to list out all the fields, and then maybe use the issue.@property notation, if you want to iterate over a list of issue fields.

[Bryan Karsh]

Well, several teams use Jira at our company. One request is that we have some mecanism in place that will pass populated fields from issues in a particular format, that can be parsed by scripts, etc.

One use case we had recently, was a customer wanted to be able to resubmit a transaction -- the ticket took the transaction -- passed the info to a script on the backend that reprocessed the transaction, and then the output from the transaction would be commented in the ticket. Basically we'd be using Jira tickets as a front-end interface for some of our tools.

The reason I am grabbing all fields is that I don't want to customize the code for this type of project vs. that type of project -- it should just grab everything (except comments), and our devs could mince/use the data as they see fit.

[JamieA]

OK... but the map you are creating is not very good for an interchange format. You should use something easy to parse... jira can create both JSON and XML representations of an issue, including all comments, history etc, not just fields.

You should reuse that... then you can just stick your bit of JSON on the message bus or whatever it is.

[JamieA]

Also note that this is pretty much what WebHooks are for - and all that code is already written.

[Bryan Karsh]

Thanks -- I had thought about XML/REST, but I couldn't figure out how to acomplish that with groovy in the post-function. Early attempts had me calling curl on a host which would reach out to SearchRequest.xml or a REST API url... but that seemed really inefficient.

Webhooks -- that is intriguing. I've never worked with them (and I will read up on it). This maybe be a naive question -- but I though webhooks required websites at both ends? I am working primarily with a bunch of shell scripts. Mostly bash, some python, occaisionally perl or groovy.

[JamieA]

> but I though webhooks required websites at both ends

Well, yeah, it does. But you can write a web server in a few lines of perl or python, even if all it does is write the json packet to a file system and call some more scripts.

I strongly recommend avoiding creating your own format... yours won't handle nicely things like lists of custom field options, comments etc. When you add that stuff all the consumers will need to rewrite their parsing code.

Might seem like a bit more work upfront but it will be worth it.

[Bryan Karsh]

Thanks Jaimie --

Let's say as a hypothetical, I can't immediately start using webhooks.

You mention that "jira can create both JSON and XML representations of an issue, including all comments, history etc, not just fields." --

Can I do that with groovy in a postfunction -- if so, what is the suggested approach?

I'm not asking you to code for me -- just point me at the correct API or whatever. There seem to be a lot of APIs that work with custom fields, and a relatively limited ones that work with system fields, and as far as I can tell, none that show all fields within an issue context.

Your Script Runner truly rocks. We are so dependent on it, that should you go comercial, we will "happily" follow you. ;)

[JamieA]

There is a module in the JIRA Importers plugin that is disabled by default - I would look at the code for that, or even call it directly (more info: https://confluence.atlassian.com/pages/viewpage.action?pageId=293830712)

Normally I would try to write some code given your effusiveness ;-) but I don't have the time right now - may have a look later.

[Bryan Karsh]

Ah --- this is more what what I was thinking. Thanks!

[Bryan Karsh]

Let me also say that Groovy is not a langauge I am very good at -- so apologies for syntactical weirdness.