OpenNMS Jira Integration


Running OpenNMS Horizon 28.0.0.
Running Jira Cloud on Atlassian

I’m trying to integrate OpenNMS with our Jira Cloud.

I was able to generate an api token. The connection is successful because the opennms:jira-verify return my few corporate detail.

The problem it looks like the OpenNMS is not providing the latest Rest API code.
When I’m trying to run
Key Name Description
Error executing command: RestClientException{statusCode=Optional.absent(), errorCollections=[]}

When trying to run
admin@opennms()> opennms:jira-list-issue-types
No issue types found for project with key ‘My Project’ found. The user making the ReST call may not have sufficient permissions.

In the Karaf.log, I’m getting this.
Caused by: org.codehaus.jettison.json.JSONException: JSONObject[“name”] not found.

So I did some research and found this.

Is there a way to solve this? I’m an admin, not a developer.
Any others having the issue?


Internally, OpenNMS uses the Jira REST Java Client ( which says in its wiki:

The Jira REST Java Client works with Jira Server, but not with Jira Cloud.

So I’m not sure there is anything we can do in this instance…

Is there a way to know if it’s something plan by the development teams to make it compatible with the Jira Cloud version?

You’d have to ask Atlassian.

ohhh, it’s on the Atlasian side. I was thinking it was on the NMS side. I will check with them. Thanks

Correct; the Jira REST Java Client library OpenNMS uses for the integration is provided by Atlassian.

I’m still trying to get that thing solve and maybe there is something that I don’t understand, but it looks the issue mentionned in that thread is solved since 2019.

We see also in the master branch that the issue to solved the [“name”] not found is merged in the Master branch.

Maybe there is something I’m not understanding, but if the master branch for that plugin is containing the fix for the issue I’m getting, why it is not included in NMS. Is this because Atlasian is not maintening it?

We depend on and build with an older version of the plugin that doesn’t contain this fix: opennms/pom.xml at 4d6099e85bdfc0778518823d8532c479818aea33 · OpenNMS/opennms · GitHub


This is what I understand. :slight_smile:
But is there any chance that the next build will include that fix? At the same time, I think that fix is only for the Cloud Version. So I believe that it can break the On-Prem version.

Except if in the config file for Jira,, there is a flag that can indicate if the Jira version use is the Cloud or the On-Prem. That way you can point to the right version.

You can absolutely create an issue in our Jira for this, but creating an issue for it doesn’t guarantee we’ll take action on it during a given release cycle. Since this is potentially a breaking change for our paid support customers, an update of this dependency would most likely target develop, which would turn into Horizion 29 sometime around November (at the earliest).

Jira server is getting sunsetted. Might want to upgrade that plugin.

I am setting up Jira for OpenNMS today. After seeing this, maybe I won’t use the plugin. Has anyone used OpenNMS to send emails to create issues in Jira?

Create an enhancement request in our Jira, or find and updoot the existing issue, if it exists.

I did it.

Because the jira integration is not working and I’m waiting the fix, I created my own setup.

I created a Jira user in opennms with the email associated my Jira helpdesk.

I created also a Jira group in NMS containing that new user.

On the different Built-in notification in NMS, I added a custom key that will be used in jira later. Key:nodeid/interfaced/… The goals is to create a unique key that identify the node and the problem.

Also for rearmed notification, I added at the beginning the word RESOLVED. This will help to auto close the Jira ticket when having threshold notification.

On those built-in notification, I changed the notification group to be my group containing the Jira user.

In Jira, I created an automation rule when a ticket is coming from NMS.

  1. if the ticket contain what I want created in Jira,.I create the ticket,.if not, I delete the incoming request.

  2. I created a custom field name remoteid.

  3. in the automation rule, I take the last line of the email containing my custom unique key created in NMS and insert it into my custom field in Jira helpdesk ticket.

  4. in the same automation rule, when an email come in from nms, with in the subject RESOLVED, I’m extracting the key I created in NMS notification email and compare it with all open ticket in JiRa. If the rule find a ticket in JiRa with the same key (RemoteID), I’m deleting the newly created ticket in JiRa, because it’s a resolved notification and I don’t want a ticket for something that is closed.

5).When the rule find a ticket with the same remoteid key, I’m transitioning the ticket to closed and add “Resolved” as comment in the original ticket.

So normally, I’m only having one ticket in Jira with my unique key.

Example of key.

Maybe not easy to to understand bit it works well.

1 Like

Nice, thanks for the pattern. Glad to hear someone else is doing this as a workaround! hah It’s really not a terrible strategy. I am going to set up the same for zendesk to see which one my team likes better.

That’s a great solution. Thanks for suggesting it!