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
Let me ask you a question. From your description, it seems like when I as a user complete a task, the process directly assigns the next task to me. If this is correct, why do you do that? Wouldn't it be better to chain that next task to me so I can continue working?
Lots of assumptions ...
In general process execution time and task activation varies and your design should never rely in it.
Hi ,
Actually it isnt another task, it is the same one, we have implemented out of the box button "Close" which should allow to the user to navigate back to the previous page without doing anything to the task and if I set a chain the user will be redirected to same task over and over and the Cancel button wont work anymore as per requirement.
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.
You can use a gateway in combination with a ri/pv buttonAction (type string) directly after the task. The moment you cancel its going to an end event the moment you go back you are chained and back at your task.
But as I am writing this, it somehow hurts as I have the feeling pretty much like Mike....we miss quite some details what the overall idea is. From a design perspective something feels ...."off?". Don't know if it's the right word.
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.