Hi All,
I have a scenario where Appian task is already created with the task display name, for example as 'Task abc with amount $100".
Now when the user opens the task form, the amount will be recalculated in local variables and and are updated in database using Store Procedure execution function in local variables .
So, every time when the form loads, the amount will get refreshed and updated in Database as well.
Now my issue is ,when the amount is refreshed, the task display name should also get refresh,
for example if the amount is refreshed from $100 to $200 , then task display name should be 'Task abc with amount $200".
Note: The amount in task will get refreshed at the time of form loads, without any user interaction inside the form.
Please help me to achieve this.
Thanks in Advance.
Discussion posts and replies are publicly visible
Task names are evaluated at assignment time and (AFAIK) not evaluated again at all. The best I suspect you'll be able to do here (though other users might have some other tricks), is to give the user a "refresh" control (button, link, etc) that secretly submits the task and loops back to it again, creating a new instance with a refreshed evaluated name. That would require 1 user click at a minimum, but as I said I don't expect you'll get a way that has zero clicks.
Can you tell us a bit more about your use case for wanting the Task Display Name to change? Generally speaking, the user won't really see it after they've opened the task, unless they abandon the task again without submitting. That's possible, of course, but seems like a bit of a corner case.
AFAIK what Mike already suggested is the only way but you can also give it a try to use "Refresh default values every time the task form is viewed" property of UIT.
I'd love to hear whether someone tests this to see whether or not it affects the rendered task display name - I'd guess no, but i'm actually not completely sure.
Mike Schmitt said:I'd love to hear whether someone tests this to see whether or not it affects the rendered task display name - I'd guess no, but i'm actually not completely sure.
I can confirm this setting does not update the task name, restarting the task is the only way to re-evaluate the task name. Running a test to confirm:
pv!num set to 1, process started for debugging.
pv!num updated to 2, task name still references #1:
Thanks, that matches my expectations (though, it woulda been nice...)
To complicate this even further - I'm wondering if this setting is a leftover from the old "Portal" form days (*shudder*).. As recently, I routinely see input values being refreshed without this setting selected.. Current Documentation. Lets run another test..
Simple interface with a CDT and a Number input:
Refresh not checked:
Process started for debugging, task shows the initial values:
I then start this separate script task which updates all 1 values to 2 in the pv's:
Task is NOT restarted, but when it is reloaded on the front end, all values are all updated anyway:
Chris said:start this separate script task which updates all 1 values to 2 in the pv's:
You didn't show how the value is being passed into the interface - is it being passed into an ACP then into the form, or straight through to the form as a directly-referenced PV? I assume these two will have potentially different behaviors keying off of the "refresh on re-open" setting. PV values I'd expect to always reflect the latest ones; ACPs I would expect (hope?) to retain their original task-instance value UNLESS that option is checked.
Mike Schmitt said:You didn't show how the value is being passed into the interface - is it being passed into an ACP then into the form, or straight through to the form as a directly-referenced PV? I assume these two will have potentially different behaviors keying off of the "refresh on re-open" setting. PV values I'd expect to always reflect the latest ones; ACPs I would expect (hope?) to retain their original task-instance value UNLESS that option is checked.
Definitely a good point to check for differences there. Per the initial test above however, they are passed as ACPs:
Changing to PVs for the re-test:
Testing with the same method as above, but direct PVs now, shows the same result. Values on the interface are refreshed in the UI, without restarting the task, and without the "Refresh.." execution option selected..
Just to note, I'm running this test on my 23.3 environment.
Chris said:but direct PVs now, shows the same result
This one at least seems like expected behavior. I am (at least slightly) surprised that it's happening with your declared ACPs, however. OK, i guess not THAT surprised. But it makes me wonder whether that setting even has any remaining material effect? Were you able to discern anything that its being selected / unselected actually changes?
Mike Schmitt said:Were you able to discern anything that its being selected / unselected actually changes?
I can't say I've seen any effects from this setting either way since those Portal days years ago, my gut says this is a leftover setting from that time and might/could be removed when Portal is officially removed from the product (it is still deprecated currently AFAIK? We just removed access to our Portal area recently). When I'm reviewing applications, I don't even check for this setting any more..
I also can't say that I've had any cases where I would not want the values in the interface updated automatically to match the process variables, so I'm not concerned with it from that point.. Any case where I would need to see an older value would be handled differently anyway.
For members here who aren't familiar with the singular version of "Portal", don't ask don't tell ;)
Chris said:"Portal", don't ask don't tell
(and count yourselves all the luckier for it...)