Hello,
I have one main dashboard that displays a readonly grid which has as datasource one expression rule in which i have a a!queryProcessAnalytics.
In the grid that I display I'm using a!processTaskLink().
The problem is in case an action is taken on one task where it should return back to the same user, it won't be displayed in the grid anymore (most of the time), only after they refresh the page.
I would like to avoid the refresh button on the page and I have also tried with refreshVariables and it doesn't work.
Any ideas how I can refresh first the grid and then display the page without being necessary to refresh the page?
Thank you!
Discussion posts and replies are publicly visible
I guess by setting the refreshAlways: true in the a!refreshVariable function is not working as well.
Unfortunately it is not working.
So the name of the setting "refreshAlways" it's false as it's not refreshing always, as it should :P
Can you share with us a bit more detail (including, if needed, some code snippets and/or screenshots), covering what you're currently attempting, as well as a higher-level "user experience" style walk-through of what you're hoping to accomplish? I stall can't quite discern what you're trying to set up here from the point of view of the user.
hi Mike Schmitt,
Thank you for your reply, with the "Close" (sort of close without saving) button I would like to allow the users to get back to their my task grid without being necessary for them to click on the tab. The problem is that sometimes (60% of the time) they are redirected faster than the reload/refresh of the a!queryProcessAnalytics and I was thinking if I'm able somehow to force the refresh first and then to redirect the user.
Thanks for the explanation - I see what you mean now. I believe this is only truly "solvable" by compromising with one of perhaps a few different work-arounds.
The issue is, as far as I've experienced, approximately, this: Having the user "close" a task with a Submit Button will submit that form and, once you break chaining, they will immediately be dumped back out to whatever interface they started on, while the process in the background might take its time spawning the new task (hence the delay you mention).
My favorite and "purest" method to deal with this is to just provide them a "refresh" icon on their task list. They'll get used to using it, IMHO.
The second best method for dealing with this, and somewhat more direct, would be to branch the user to a different (chained) "confirmation" task, where the only information in that task is text saying "your task has been moved back to your task list" (etc). The user is chained to this task while, *simultaneously* in the process, the original task (node) has been returned to, and by the time they hit the "close" button on the Confirmation task, the original (real) task will have spawned and will be waiting for them in their task list. The main cost here is it adds *one click*, though most people won't care that much about a single additional click in cases like this.
Hi Mike Schmitt i think I will go for the second method since the first one it isn't in the acceptance criteria but I would like to ask you more about that, the "confirmation task" should be a!startprocess with chaining and it should have a time for end event, in order to not hold it as forever in memory. In case I set another task in between then it will be the same story.
Andrei Iordache said:the "confirmation task" should be a!startprocess with chaining
No - the confirmation task would just be chained-to in the same process. I see no need to bring a!startProcess() into this, and in particular, it wouldn't (and couldn't) do what you want it to do anyway.
Edit: here's a sketch of how this would be configured. From the user's perspective this will function very simply. From a process perspective as well.
I will go with the second method, thank you for that!