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; } } }

Jira and plugin version info stored with issue?

Adam Saunders_p37j93

Information we're looking for:

- Jira server version

- Installed plugins / versions

We would like to store / retrieve this information for when an issue is created and for when modifications are made to an issue. Is this stored with issues in any way or is there a plugin to do this?

Usage examples:

- List all issues created with Jira version < 6.2

- List all issues modified / created with ExamplePlugin version 3.3 installed

Thanks.

Accepted answers

Nic Brough -Adaptavist-

No. An issue is an issue, it doesn't care about the version of JIRA or plugins etc.

You could put in a hideous kludge - add fields to contain the data and write a bit of code to store it.

A better option would be to log all your upgrades properly, store the dates somewhere safe, and then you can compare the issue created date with it to establish what was there when the issue was raised.

(Although, I also want to ask "why", as I can't think of much use for this)

All comments

Nic Brough -Adaptavist-

No. An issue is an issue, it doesn't care about the version of JIRA or plugins etc.

You could put in a hideous kludge - add fields to contain the data and write a bit of code to store it.

(Although, I also want to ask "why", as I can't think of much use for this)

Adam Saunders_p37j93

Storing the date was the closest I could think of as well. Was hoping to automate it by retrieving version info directly. We have several plugins, projects, issues types, and custom fields using plugins. Figuring out which fields in which issues need to be checked if we update plugin X would be time consuming.

As to why:

As part of our audit requirements we have to be able to prove that we performed validation / testing of all third party software we use, including upgrades or modifications to that software. We have to prove that upgrading a plugin did not break anything. For example, prove that upgrading JEditor did not break formatting on any existing issues that use JEditor fields.

The easiest way to check would be to find issues / fields created or modified with the previous version of JEditor and verify that the formatting is not broken after an upgrade. It gets a bit overwhelming considering we have 10+ plugins as well as varying issues / projects that do or don't use the JEditor fields. Doable, but was hoping to automate it.

Nic Brough -Adaptavist-

Sounds like an odd way to conform to an audit to me. You'd normally test it before promoting to production, and record that. Having historical access to data that might be affected doesn't tell you anything. Plus, "figuring out which fields in which issues needs to be checked" is not a proper test. You should be checking everything, every time. I've managed to write broken code that breaks *other* fields on issues, ones it is not supplying - many add-ons can indirectly break things not directly related to them.

Adam Saunders_p37j93

This info would not directly put us in compliance. It's a quick way to identify reasonable and easy conditions inside boundaries. Failing this test would be quick indication of a problem. Conditions outside these boundaries would have to be handled some other way after this passes. It would be one item to sign off on in a whole procedure. This would not be done in production.

Anyway, I digress.

Welcome!

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

Quick Links

Find more posts tagged with

jira