It's all about the answers!

Ask a question

When using a script-based calculated field on a work item, how can I tell the Web UI to refresh the field?

Davyd Norris (2.2k217) | asked Jan 14 '19, 10:29 p.m.
Hi all,

I have a client that wants to calculate fields on a work item when the Filed Against (category) is changed. Specifically, they want:
 - the Summary field to be automatically generated based on the assigned category, and
 - the Owner field to be set to the person who has the role of Team Lead in the team assigned to the category

I have created calculated value scripts that do both of these things, but both of them require web lookup calls and so they use the workItem.setValue() function to set the value rather than blocking the UI.

This is working fine for the Summary field, which is text, and which appears to update virtually immediately as the user changes the Filed Against field. However, this is not working for the Owner field, which does not reflect the new value until the record is saved. In addition, I get two additional messages in the console
- the first one occurs when the old Owner is not a member of the team belonging to the new category
 - the second one occurs when it gets a change notification from the setValue() function but doesn't think the value has changed.

I can ignore the messages in the console, but I really need to be able to show the changes in the UI before the record is saved.

Is there any function I can call that will force an update or refresh of the Owner field to reflect the changed value?

Please note - this is a CLM on Cloud instance and so I have to handle the update in Javascript on the client side. I can't use server extensions.

2 answers

permanent link
Davyd Norris (2.2k217) | answered Jan 23 '19, 7:49 p.m.

Bumping this up again - hopefully one of the RTC devs can help out?

permanent link
Lawrence Smith (3764) | answered Jan 24 '19, 9:06 a.m.

 Check that you set the owner as dependent upon the category in the work item attributes configuration?

It may work to make the owner dependent on summary also then 

a) Change category
b) Load owner and summary
c) setValue on owner
d) setValue on summary
e) Now the script for owner will be called again, so you detect that the new value is already set from (c) so ignore it, 
but the owner field may be refreshed with the value set in (c).

Or alternatively set summary dependent on category and owner dependent on summary...

a) Change category
b) In summary script: Load both owner and summary asynchonously
c) When both loaded setValue on summary
d) Now the script for owner will be called (dependent on summary) and setValue on loaded value.

The attribute model for the owner widget is connected to the current working copy so you need to be sure when the owner is set the "right" working copy is used which may not be the same as before the async call was made.

Davyd Norris commented Jan 25 '19, 6:47 a.m. | edited Jan 25 '19, 6:53 a.m.
Thanks for the suggestions - they made sense but unfortunately didn't work.

I already had Owner dependent on both category and target (target is actually a default setting because of the potential Category to Team links I guess). I then added Summary as well but it still didn't change - it only refreshes upon save.

I will try the second approach as well and will try to set both in the Summary change code and see if I can make it trigger.

I've noticed similar type behavior on another customisation I've done where I use async web calls to get a related a team of people and automatically create a review that includes them once the record is in a certain state. It all works but the review/approval only shows up after the save. That's less important as I actually only want it to be visible once the state change has happened

Can I somehow use getProxy on the passed in workItem parameter to then access and save the correct working copy?

Davyd Norris commented Jan 25 '19, 6:48 a.m.

I'll try the second approach as well and see how that goes - where I set both in the Summary change code

Your answer

Register or to post 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.