Attribute customization - How to prioritize calling the calculated script before Operation behavior on save
Hi All,
I need to call the calculated script before Operation behavior on save.
This is the current scenario [Was able to achieve steps 1 to 5, but not able to succeed through steps 6 and 7] : Could you please help me on this.
1. Defined an attribute say.."LinkCounter" of type integer
2. Added a calculated script that contains the Oslc URI to get the count of "links" for the current WI (It usually returns the count of number of WI linked to it...eg ...0(zero) for no links present, 1 for one link present etc)
3. On a particular state...say "Set Done" state, I have a "operation behavior" set as "required for type and attribute" for this attribute "LinkCounter".
4. Then on changing through different states, when I am about to set it to "Set Done State" It check for the LinkCounter value. Since there is no link for the current WI, It will be the default value "0 zero".
5. As the operation behavior is set, It doesn't allow me to save the WI [error message : Attribute"LinkCounter" not set ]
This is the main area to be highlighted :
6. I now link some WI to this current WI. So that count of the attribute would become 1.
7. But the calculated script is not dynamically called and 1 is not getting updated on click of save button.
I am getting the error message : Attribute"LinkCounter" not set
Is there any way, I can call the calculated script before the opeartion behavior is set on the attribute ? so that when I create links to the WI, it calls the script and value is updated and then the operation behavior is called.
Thanks in advance
|
2 answers
According to the document https://jazz.net/wiki/bin/view/Main/AttributeCustomization#Calculated_values :
If you configure a Script-based calculated value, the script will be executed in three cases:
Comments
Shwetha G
commented Dec 21 '16, 11:27 p.m.
Hi Lily,
1
Lily Wang
commented Dec 22 '16, 1:01 a.m.
The problem is when you add a link to the current WI, the calculated value provider script will not be triggered so it still remains as "0". Then when you try to save the WI, the pre-condition fails.
The possible solutions are:
- as Donald suggested, use a follow-up action. After adding a link, save the current WI to make the follow-up action update the LinkCounter. Then change the WI status to "Set Done" and save it again.
- otherwise, you can add a dependency between LinkCounter and WI State to make the value provider triggered before saving WI. In this case, you still need to add link first and change WI state after that.
Really really thanks for your reply Lily.
Shwetha G
commented Dec 22 '16, 2:55 a.m.
Really really thanks for your reply Lily.
Really really thanks for your reply Lily.
Shwetha G
commented Dec 22 '16, 3:00 a.m.
Donald Nong
commented Dec 22 '16, 3:15 a.m.
You cannot expect a detailed implementation from the forum. Have you added the attribute "LinkCounter" in the WI editor, as hidden? If it's not there, I'm not sure the calculated value script will ever run.
showing 5 of 7
show 2 more comments
|
You have two issues to deal with here.
1. Attribute"LinkCounter" not set - to avoid this, you should use a "default value" provider. It is reasonable to set it to 0 as when the work item is created, usually there should be no links attached to it. 2. Automatically change "LInkCounter" value when a bi-directional link is added outside of the work item. I am pretty sure in this case the calculated value script will _not_ be called (for the target work item). You may have to develop a follow-up participant in the source work item to change the "LinkCounter" value directly, say +1. But if the source is from QM or RM, I am not aware of any means to do it automatically. Additionally, you may also need to consider the situation where a link is _removed_. Comments
Shwetha G
commented Dec 21 '16, 11:41 p.m.
Hello Donald,
|
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.