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?
- List all issues created with Jira version < 6.2
- List all issues modified / created with ExamplePlugin version 3.3 installed
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)
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.
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.
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.
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot