Assigning current Time Stamp when defect is resolved
RTC 4.0.6 used(Eclipse 4.0.6)
I followed the example in the below post to assign current time stamp when defect is reolved: https://jazz.net/forum/questions/94742/assigning-current-time-stamp-upon-closure-of-defects 1. Create a script based calculated value (see below script) 2. Create a new timestamp attribute fixeddate for the defect work item 3. Select the script created in step 1 in the "Calculated Value" dropdown of the new attribute 4. Configure the new attribute to have a dependency on the "Status" attribute. 5. Add a read only presentation for new attribute to the defect editor When creating a new defect, fixeddate will show None. When set defect to resolved. nothing changed in fixedate. I have set Enable Process Attachment Scripts property to true. What did you do wrong? It seems to me I did the same as in the above post both Moti and Joan run successfully. Thanks --script-- dojo.provide("org.example.workitems.providers.FixedonDate"); dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes"); dojo.require("dojo.date.stamp"); dojo.require("dojo.date"); (function() { var WorkItemAttributes= com.ibm.team.workitem.api.common.WorkItemAttributes; dojo.declare("org.example.workitems.providers.FixedonDate", null, { getValue: function(attribute, workItem, configuration) { var currentDate= new Date(); if (workItem.getValue(WorkItemAttributes.STATE)=="3") { return currentDate.getTime().toString(); } return 0; } }); })();
showing 5 of 6
show 1 more comments
|
Accepted answer
Hi Don,
Working with Date/Time is a bit fiddly, it worked for us returning the value in the following way:
return toISOString(new Date(), {milliseconds:true, zulu:true});
Incidentally, the dependencies appear to do very little when running scripts. It doesn't do what you expect it to do. We have found that scripts will run always, whether you have dependencies or not. Same goes with Condition script, even though you set it on a specific field and set a dependency, it will always run. The whole scripting environment is a bit of a black box! We are using 4.0.3.
Don Yang selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Don, I'm not sure your logic is complete. I believe your script as documented here will update your custom timestamp every time a change is made after the workitem is resolved. You may want to extend the logic like this (you may find a more elegant way of doing the same thing):
if (workItem.getValue("fixeddate") != null && workItem.getValue(WorkItemAttributes.STATE)=="3") {
return workItem.getValue("mydate");
}
if (workItem.getValue(WorkItemAttributes.STATE)=="3") {
return currentDate.getTime().toString();
}
return null;
Thanks Brian for the suggestions.
I understand that your logic is to count the situation when there is some update on the resolved workitem without changing the state(the same timestamp will be set) as well as changing to other state from Resolved(such as reopened: the timestamp will be set as Null).
I tested it and it works for me although I have to use toISOString(xxxx, {milliseconds:true, zulu:true});for the right timestamp.
Interesting that we need to use different methods to make this work. I tested this on RTC 5.0, using Firefox 24 with a Windows 7 Tomcat/Derby deployment. Out of curiosity what is the OS and App server you are using?
I tested with v4.0.6 on Win 7 Tomcat/derby and tried it on Eclipse client (4.0.6) only so far.
I found that when the state is resolved, the timestamp is set. if I only added some description in this state, it will still update the timestamp to latest one. In your script, return workItem.getValue("mydate");
What is "mydate" here? How did you set the value to this variable?
Thanks
Sorry, typo. Should have been "fixeddate".