|
|
|
This would also allow searches like 'Issues resolved by Fred'.
This will solve a lot of practical cases.
It seems I'm missing simply abilities as "search for bugs/items" I worked on. Once a bug is assigned to someone else I cannot easily find it. So at the end of the week I'd like to see all th eitems I worked one (now they are assigned to various persons in QA). I cannot do this because if I search by my user id I'm not getting them. Same here...
At our company, it would be greate for QA if we could track how many times issues have been moved between projects (and back, as is the case sometimes)... Project managers are really calling for this in our company. They want to create reports that show how issues are moving from version to version or in our case from milestone to milestone which we track in our Versions for large projects.
That's exactly what our company wants to do too, see how bugs are moving into and out of Milestones.
Currently we're considering making a Listener that will detect changes to the Fix version field and update some external document. Or maybe it would be possible to write a plugin Report that can show change history info.. I think it's going to be messy either way. I curious if the {sql} macro in Confluence can be used query JIRA's database. Confluence is used for our project documentation and status so this would be an acceptable means for getting at this data. It's not clear to me if I can configure Confluence such that the {sql} macro can access the JIRA database. Both Confluence and JIRA are on the same MS SQL server.
Kevin,
It should be possible to configure the sql macro to access JIRA's data source, if JIRA and Confluence run in the same app server. Anton Is there any movement on this issue?
It seems it would be a very popular feature, and it would certainly make our lives a lot easier when it comes to reporting on issues that have changed versions/milestones. Can you provide an estimate as to when this feature will be implemented? Hi Rick,
This is a popular issue, but we have feature requests that seem to be even more sought after. Unfortunatley at the moment I do not have an ETA for the implementation of this issue. Thanks, As a PM responsible for implementing Jira, I know this would come in handy. Being able to gather metrics on the ratio of issues that are incorrectly resolved/closed, the average number of times an issue in a given project/version are resolved/closed, and all of the examples above apply to my group too.
Bump for this issue as we also require this functionality. Any update on this?
Thanks. I am also very interesting by this new feature. We should do some reports and I should do some SQL requests, and it is not very simple, users want always new requests : nb of issues moved for a project, nb of issues on which a personn has been assigned at least once ...
I am also interested in this behavior. Currently we have to do some networking on our side, i.e. opening ports, creating read-only accounts, in order to query the database. Is there an ETA on when this feature will be implemented?
Managers in our company are requesting the ability to breakdown issues updated by a particular JIRA user in the past week. Also, they'd like to see the issues resolved by a particular developer in the past week. Simply filtering on Assignee and Status=Resolved (as some have suggested) implies the assignee has not been changed since it was resolved which isn't always the case. We're needing to see this capability in JIRA more than ever now.
I think that linking and closing RA-5740 "How To Tell How Many Issues A Developer has resolved" was a bad decision. I see this thread as "search" oriented. That is not what I require.
I want to be able to get a report of how many bugs each developer solved last month. The "search" way of thinking is not the right one. It is also demonstrated to be very trivial. You have already added a custom field called "shutdown", which gets written when a user resolves an issue. That field was made to support the charts "Created vs Resolved Issues". All you need is to add to the SAME callback/action, the writing of not only the date, but the user that changes the status to Resolved. Then we can all run a report that shows who resolved what bug. I see it as so basic and easy, that I assume that either I don't understand why my description is simply incorrect, or, I am the only one that really wants this report. Otherwise, I don't see how this feature was requested in 2005 and still not done. We need this so users can answer the question, "What issues have I touched in the past?" - Voted!
We need this for weekly review. It is great hassle to play around with SOAP scripts and saving data aside to get necessary history data.
We need the ability to export the change history to be able to find out how many tickets during a week were re-opened, how many tickets were actually resolved by an analyst, etc.
This is a very important KPI to measure our teams effectiveness. Please start working on it. Thanks Simon,
Since this isn't on the roadmap for any upcomng release, and you seem to need this soon, you might want to look into a direct SQL query against the database that will get you the information you need. Here is an example that shows all changes that set or removed a resolution. (resolved or reopened the ticket). It also shows who executed it and the execution time. You could take this export and put it into excel to satisfy both of the requirements you mentioned. SELECT propertystring.propertyvalue as "Executor", changegroup.created, changeitem.oldstring, changeitem.newstring FROM changeitem INNER JOIN changegroup ON changegroup.ID = changeitem.groupid INNER JOIN jiraissue ON changegroup.issueid = jiraissue.id INNER JOIN userbase ON changegroup.author = userbase.username INNER JOIN propertyentry ON propertyentry.entity_id = userbase.id INNER JOIN propertystring ON propertyentry.id = propertystring.id WHERE ((changeitem.oldvalue is null and changeitem.newvalue is not null) OR (changeitem.oldvalue is not null and changeitem.newvalue is null)) AND propertyentry.entity_name = "OSUser" AND propertyentry.property_key = "fullName" AND changeitem.field = "resolution" Thanks for this. There's quite a bit of hassle involved in obtaining production access to our JIRA database (we're an investment bank and SOx prevents a lot of this), we'll look into it, however, I feel strongly that this should be a core requirement for JIRA reporting so should be prioritized.
Simon, if you have some development resources, you may create a report, we did it for ourselves. It's too difficult to add ability of searching change history into Find Issues page as I know.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
> We work with an external support contractor that wants to have a weekly report on the issues that where once assigned to his company and have been reassigned to someone of our company.