Jira and plugin version info stored with issue?

Adam Saunders June 21, 2017

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.

1 answer

1 accepted

1 vote
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 21, 2017

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)

Adam Saunders June 21, 2017

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 21, 2017

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 June 21, 2017

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 21, 2017

Yes, it's an interesting digression, but you're right, I think it's a different topic ;-)

The klduge option will work, where you store version data against an issue, but it's going to make your data grow alarmingly fast, for no benefit to the users.  I'd still go with "proper logging of upgrades" and then some custom development that can pull the data you're looking for from issue histories.

Suggest an answer

Log in or Sign up to answer