nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to keep track of a issue without storing state?

Rick van Dam

We are working on integrating https://www.uptrends.com/ with jira for our clients. One of the things we do is generating a alert if a website is down. In this case we want to create a issue in Jira. This is quite easy to do with the REST api.

However we also generate a OK alert once the website is up again. We would like to close the issue we created in this case. Our integrations are stateless so its not possible to store the Id that Jira generated. I was looking at externalId to keep track of the created issue where we can put in our own id to do this but I noticed it was removed.

Is it still possible to integrate with Jira in this way or is there no way around keeping track of state and storing the Id that Jira generated?

Accepted answers

All comments

Nic Brough -Adaptavist-

You already mentioned populating externalid on the Jira issue - I'm not sure that's the right place, as you say it was removed (I think it's limited to being written when importing).

But it's a good approach - create a new custom field to store the reference your application sends over.

Then, when your application wants to close the Jira issue, you can use REST to search for "external id custom field = ########", that will return a list of issue keys (only 1 if the id is unique of course), which you can then issue "close" for.

You don't have to do it with a field though, if your created Jira issue has data you can identify it with. A really simple search might be along the lines of "project = X and issuetype = server-down and status = open"

(I'd actually recommend using that query with "and external id custom field = ######" too, as it'll make the search faster)

Rick van Dam

Both of those solutions have their flaws though.

The first one requires the customer to add the field themselves.

The second one would force some naming convention on the customer

In both cases the customer has to be careful not to edit the fields as well

Nic Brough -Adaptavist-

Not quite, the process of creating the issue can be done by your process. (And if you don't put the reference field on the Jira "edit" screen, then your humans won't be able to change it and you could define what ever scheme you want).

The problem is that whatever the process is generating and putting into Jira, you're throwing it away on the non-Jira side, so the process can't use it to re-find the Jira issue later. Unless you can come up with some way to re-generate the id so it can know where to look.

There's one relatively easy option - stamp "system date/time" on Jira. Your process could regenerate that by looking at when it might have needed to create the issue. But the better option is something simply unique that your process generates and stores.

Rick van Dam

We have a id that stays the same for the same 'alert' so regenerating the id is no problem.

The problem is that its not possible to simply add a field. You will run into this error:

```

{ "errorMessages": [], "errors": { "uptrendsid": "Field 'uptrendsid' cannot be set. It is not on the appropriate screen, or unknown." }}

```

The user first has to add this field to his instance before the api call will work. We would like to avoid this manual step.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud