|
|
|
You could create a filter that finds all resolved issues with an updated date between the specified range. This does not give you exactly what you are after, but is a good start.
Alternatively, you could create a custom field that gets populated with the date/time during a transition or populates it's self based on the Change Item. I don't think it would be too hard to accomplish. Cheers, The filter idea is what we use, but it is full of false positives. When someone goes through and bulk edits a bunch of issues, they all appear as if they had just been fixed again. Yuck.
We desperately need a date of last activity column, which would only get updated when a workflow action is taken ; e.g. when an issue's status is changed via workflow, from open to resolved, you could search for resolved issues, you'll only find issues that were resolved as of that date.
The data is available, for most cases, in the DB without adding custom fields. I had to create a report for our company that would show the items resolved each month and the work logged against them. I considered issues that changed to resolved (looking at the change history). This means that some issues would be resolved twice because they had been reopened and then resolved again, but that is an accurate reflection of the activity. I have SQL that I use to build this report today.
The only place we have had trouble with this is when we imported issues from a CSV file. The change history did not exist, so items that were imported as resolved did not appear in the results. Other than that, it works well - we just need to have it integrated. As for finding issues that were resolved for a release, why wouldn't the Fix Version field work? We rely heavily on that for our change notes and it has been working well. Thanks for your notes, Jami. I can answer your last question, as it pertains to me.
I am QA as well as release manager. I decide what gets into each release based on what has been fixed by a certain date. It's quite different from Atlassian where issues are targeted for a release, and the release is made when all the issues have been fixed. if some don't get done, their fix for version is changedby the developer(s). Our developers don't care about the Fix For version field. I manage it. I set a fix for version, which to me, is a target. So, I routinely look for issues that have recently been resolved, and if they pass test, I set the fix for version to be the next version to be released. As to the availability of the change history thru SQL, I'm looking for something built in to the Find Issues search filters. I don't need a once in a while report - I am constantly filtering and/or sorting by date updated. We solved the release problem in a different way. We create a release called 'Next Release' and all issues that are assigned to developers are given this Fix for version. Looking at our Roadmap, we have hundreds of issues in Next Release, but only a fraction of them are resolved.
At the point we want to make a release, we rename this release to something like 'Prodname 20050110'. We then create a new release called 'Next Release'. At this point, we can release 'Prodname 20050110' and JIRA will prompt to move unresolved issues into another release (we pick Next Release). This process works well for us. The only part I don't like is that it is difficult to formally schedule items - everything tends to just get dumped in 'Next Release'. I definitely would appreciate the option in the filters - I commented mainly so people would know that it can be done with the existing data. The information is there, just not yet easy to access. Too funny
Issue Closed / Resolved dates as individual fields would only add to the flexibility and usability of Jira. Any analysis you want to do on what types of issues take longer to close in chronological time (vs. worked time). All that kinda stuff...
I'm interested in your SQL, Jami for items resolved. there is a plugin that can help with this:
http://confluence.atlassian.com/pages/viewpage.action?pageId=195827 ( Closure - Resolution Fields & User or Group Tracking Report Plugin) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
JRA-7451as they appear to be duplicates.