[#JCHART-20] There are only added a resolution date if closed from ReOpened

JIRA Charting Plugin

There are only added a resolution date if closed from ReOpened

Created: 20/Feb/06 08:05 AM Updated: 08/Apr/08 05:41 PM

Component/s:

None

Affects Version/s:

1.1.1

Fix Version/s:

None

Security Level:

public (Anyone can view the issue)

Time Tracking:

Not Specified

File Attachments:

ResolutionDate.java (2 kB)

Image Attachments:

1. Resolution date not stored.jpg
(238 kB)

2. Resolution date not stored.jpg
(238 kB)

Environment:

JIRA 3.5

Issue Links:

Reference

This issue is related to:

~~JCHART-162~~ Resolution date not set on close screen

Labels:

Description

« Hide

I do like the JIRA Charting Plugin but it only stores a resolution data when I close an issue from the Reopende state with a transaction Close.
If I close an issue from the open state with transaction close the issue is closed but not with a resolution date.? The used Screen for Close from Reopened and open are the same, and the conditions are the same also.
I have 4 workflows in the JIRA system and they all works the same regarding this problem and they are all home made.

Issues types:
TroubleReport; workflow dev.
New Feature; workflow dev.
Improvement; workflow dev.
Task; workflow Task.
TestCardSupport; workflow Support.
TestCardOrder; workflow order.
TestCardPorting; workflow order.

Hope that you can help me here.
Jakob F. Gormsen,PMP

All

Comments

Work Log

Change History

FishEye

Crucible

Builds

Sort Order:

[ Permlink | « Hide ]

jakob Gormsen added a comment - 20/Feb/06 08:29 AM

As you can see the resolution date is not stored, INF26-24 were closet again from Reopened and there for the issue has an resolution date. If you need I can send you a backup of the system but will be to a company Email and I will encrypt it with a PGP key Please pelp.

[ Permlink | « Hide ]

Mike Canon-Brookes (Devsuite) added a comment - 22/Feb/06 07:39 PM

Jakob,

As these are workflows you've written yourself - are you sure the resolution field gets set during these other transitions?

What database are you using?

Cheers,
Mike

[ Permlink | « Hide ]

Dominique BERTRAND added a comment - 23/Feb/06 08:25 AM

I have the same problem and I used postgrey database.

Thx

Dom.

[ Permlink | « Hide ]

jakob Gormsen added a comment - 24/Feb/06 02:08 AM

Hi,

The problem is solved by updating the JIRA to Version 3.5.1 and the Jchart to 1.1.2.
This seems to have solved the problem.

Yes, all the work flows are home made, and we are aware of stetting the resolution field every time. (-:
The schreen shot i attatch to the issue shows that the resolution fileld is set but there are nu resolution date.

We use the postschriptSQL for JIRA.

Jakob F. Gormsen,PMP

[ Permlink | « Hide ]

J. Longman added a comment - 08/Mar/06 08:00 PM

I had the same problem with Jira 3.5 and JChart 1.1.1, so I just upgraded to Jira v.3.5.2, with JChart 1.1.2, and still the same problem. I also have a custom workflow (a Review state between In Progress and Closed). I am using MSSQL/jTDS on Java 1.5 on Windows.

IIRC my workflow fires an "Issue Resolved" event when transitioning from the Reviewed to the Closed state.

Incidentally, do the installation steps need to be re-done when upgrading? e.g. remove the custom field, re-add it, re-index?

[ Permlink | « Hide ]

jakob Gormsen added a comment - 09/Mar/06 02:15 AM

Hi all,
In my last comment for this issue I wrote: "The problem is solved by updating the JIRA to Version 3.5.1 and the Jchart to 1.1.2."
After working with the system I have come to the conclusion that this is not 100% correct.

I have seen that the charts displayed by the plug-in is not always correct regarding the number of issues that has an resolution date.
After investigating this problem I have seen that making a manual re-index solves the problem.
This is not a fix but a workaround that we can live with. We have set JIRA do re-index every hour.

[ Permlink | « Hide ]

J. Longman added a comment - 09/Mar/06 05:07 PM

Jakob's workaround does not work for me. I will maybe try to remove the plugin and re-install it.

[ Permlink | « Hide ]

J. Longman added a comment - 09/Mar/06 06:20 PM

i removed my resolution date created when I installed the earlier version of the plugin, readded it, re-index and voila, it appears to be working!

[ Permlink | « Hide ]

Philippe Kernevez added a comment - 20/Mar/06 07:04 PM

The workaround doesn't work for me too.
I don't try to desinstall the plugin and re-install it at this time.
My configuration is : MySql / Tomcat Jdk 1.4 / Jira 3.2.5 / Chart plugin 1.1.2

[ Permlink | « Hide ]

Sean Rees added a comment - 31/May/06 11:12 AM

I had this problem on our installation: JIRA 3.6, Tomcat 5.5, MySQL 4.1.12. It seems that the plugin (or something else) was storing a NULL_TIMESTAMP in the custom field storage. This broke this check in com.atlassian.jira.ext.charting.field.ResolutionDate (ResolutionDate.java:30)

// if issue is resolved and db value is null, then calculate date and store
if (issue.getResolution() != null && dbDate == null) {
...
}

I "fixed" it by:
if (issue.getResolution() != null && (dbDate == null || dbDate.equals(NULL_TIMESTAMP))) {
...
}

So, now Resolution Date shows the date properly (this includes showing the date if an issue was transitioned through the standard Open->Resolved->Closed path and through the less-frequent Open->Closed transition).

This fix applies to the latest trunk (rev2060) from svn.

[ Permlink | « Hide ]

Sean Rees added a comment - 31/May/06 11:14 AM

Attaching my "fixed" ResolutionDate.java.

[ Permlink | « Hide ]

Troels Arvin added a comment - 12/Jul/06 03:24 AM

It seems that the fix has gone into http://svn.atlassian.com/svn/public/contrib/jira/jira-charting-plugin/trunk/src/java/com/atlassian/jira/ext/charting/field/ResolutionDate.java

I suggest that this issue is scheduled for the 1.2.4 release.

[ Permlink | « Hide ]

Erik Serating added a comment - 23/May/07 10:55 AM

This fix has not made it into any branch or release of this plugin. I was forced to add Sean's fix and build my own plugin. The fix works but I should not have to add this fix every time I upgrade this plugin. Please add this fix into the plugin code.

Thank you.

[ Permlink | « Hide ]

Reid Sayre added a comment - 09/Oct/07 03:42 PM

Standard comment when Atlassian suggests: "Here is a source code change":

We are not Java programmers. The only place we use Java is with Atlassian Products. Atlassian does make great products and we buy them because we are not experts in developing for ourselves the kinds of products that Atlassian sells.

We have resisted making source code changes because we know that we will have to look at it again the next time we update an Atlassian Product. And we do that a couple of times a year. After a while, it gets expensive in person hours.

So, PLEASE, when you have a fix that you know works, add it into the code base so we (and hundreds of other folks) don't have to take time to make sure the source code change we put into the last update still works in the latest update.

[ Permlink | « Hide ]

Reid Sayre added a comment - 09/Oct/07 03:47 PM

For JCHART-20, ~~JCHART-162~~ describes a workaround suggestion to change the workflow screens and then new data will be correct.