It's all about the answers!

Ask a question

How to get calculated value script to fire when status is changed?


Becky McDermott (90120) | asked Sep 04 '19, 3:14 p.m.
I have added an attribute customization that is a "Calculated Value".  My script is called "storyPointsBlankOnInvalid" and I want this script to be triggered when the user changes the Status/State.  I don't care about the previous state, I just want to see if the Status is a certain value and if so, I want to re-calculate story points.

My problem is that I cannot get the script to fire even though I have made the built-in attribute "Story Points" a "Calculated Value" that depends on "Status".

My script is very simplistic at this point (just trying to see if the script is firing):

dojo.provide("com.example.storyPointsBlankOnInvalid");

(function() {
    dojo.declare("com.example.storyPointsBlankOnInvalid", null, {

        getValue: function(attribute, workItem, configuration) {
       
        alert("Inside HERE");

return workItem.getValue(attribute);

        }
    });
})();

currently, if I change the status/state of a "Story", the alert is NOT displayed (the depends on "Status" is not causing it to fire).  If I also make it depend on "Filed Against" and then change that field in the story, the script does fire (alert is displayed).  But, I cannot make it fire on a change to Status/State.

Everything I have read indicates that this should work.  Am I missing something?

2 answers



permanent link
Ralph Schoon (56.6k23642) | answered Sep 04 '19, 3:39 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Sep 04 '19, 3:46 p.m.
https://jazz.net/wiki/bin/view/Main/AttributeCustomization does NOT indicate you can detect a state change in a calculated value. In fact, if you read it carefully, it says the opposite. I have answered this very same question on this same forum so many times, to call me being fatigued is a stretch. https://jazz.net/wiki/bin/view/Main/AttributeCustomization#API_for_Javascript indicates a state change is only detectable in a condition - that is it, unless you abuse storing the old state in another attribute. You can only read and determine the CURRENT state of the work item. The state change action is available only in CONDITIONS.


The API does not provide what you want at the moment. My discussions with development in the past indicate that abuse of the APIs, and its performance impact, is one of te reasons for not enhancing the API support.

Comments
Becky McDermott commented Sep 04 '19, 5:06 p.m.
I know you have answered this issue on the forum before but the answers are still fuzzy to me.  The fact that I can select "Status" in the "depends on" is strange to me (suggests that I can trigger based on this attribute change).

Basically, all I am trying to do is to blank out story points when a story is set to the "Invalid" state.  I explored conditions but this doesn't seem to do what I want.  I guess to do what I want, I could add a custom attribute called something like "blank out invalid attributes" (checked or not checked), make the "Story Points" attribute dependent on this new attribute, and then the script will fire.  Then I can check the state and if the state if "Invalid", I can zero out the Story Points field.

If you can think of a better way, please let me know. 


Ralph Schoon commented Sep 09 '19, 6:34 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I know that what you ask for has been done before. In this case it might not be necessary to detect a state change. It might be enough to be able to determine the current state. I would suggest to try Davyds suggestion. I can not tell if it would work at the moment. The point is, from my perspective, when the calculated value is actually executed. E.g. the user selects the action to change the state and presses save. Is the calculated value calculated after the save and now the user would have to save again? 


You would need to play around with this.


permanent link
Davyd Norris (6966) | answered Sep 08 '19, 2:43 a.m.
edited Sep 08 '19, 2:43 a.m.
I've found that calculated value scripts are sometimes run on the server as the data is fetched or stored, so I would check both the ccm.log file as well as the web console.

I have to make a small correction to Ralph's comment above - you can access the current state of the work item from any script that has a workitem parameter (pretty much all scripts), but you can only access the chosen workflow action from a Condition.

So, if you're trying to blank out values when the work item is saved in a certain state then this is entirely possible, but if you're trying to do something to a work item at the moment somebody selects an action to change the state then you can only do that in a Condition.

If you can first change your script above to use console.log instead of alert, and then run it and check both the web browser console and the ccm.log file, then that will tell you if and where the script is firing. Once we know that it's actually being called, we can help you with the script, but it will look a bit like this:

dojo.provide("com.example.storyPointsBlankOnInvalid");

dojo.require("com.ibm.team.workitem.api.common.WorkItemAttributes");

(function() {
    var WorkItemAttributes = com.ibm.team.workitem.api.common.WorkItemAttributes;

    dojo.declare("com.example.storyPointsBlankOnInvalid", null, {

        getValue: function(attribute, workItem, configuration) {
            if (workItem.getValue(WorkItemAttributes.STATE) === 'the.id.value.of.your.state') {
                return ''; /* or whatever a blank value is for this attribute */
            } else {
                return workItem.getValue(attribute);
            }
        }
    });
})();


Comments
Ralph Schoon commented Sep 09 '19, 6:43 a.m. | edited Sep 09 '19, 6:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I think my answer is on point. The thing is that there is nothing in a calculated value that would (easily) allow you to detect a state change. You can get the current state by reading the state attribute. There are no real means, I would be aware of, to know the previous state. 


There is a work around which is really really ugly: It is possible to store the current state in a custom attribute every time it changes, which would allow to detect a state change. Note that this has impact on the work item history, as the attribute is not hidden from anyone. So, I would not recommend to do this.

Only in a condition it is possible to know the selected action, indicating a state change is happening.  

For what the attribute customization is supposed to be used, it might be enough to know the state of the work item.


Davyd Norris commented Sep 09 '19, 10:01 a.m.
Hi Ralph, the OP specifically asked "I don't care about the previous state, I just want to see if the Status is a certain value and if so, I want to re-calculate story points."

That was why I replied - your response is all true, but she's not interested in picking up the actual change, only the current value

Davyd Norris commented Sep 09 '19, 10:03 a.m.
Hi Ralph, the OP specifically asked "I don't care about the previous state, I just want to see if the Status is a certain value and if so, I want to re-calculate story points."

That was why I replied - your response is all true, but she's not interested in picking up the actual change, only the current value

Your answer


Register or to post your answer.