-
15. Re: releasing 3.2.Beta1
I noticed this same issue when I was working with Seam and jBPM several months ago. The way tasks are implemented at a start node, they are not created automatically, but must be explicitly created. Seam did not know this, so it would not create startTaskInstances. The web console always did it, assuming that there were always startTasks. Which is true for the web sale process but not true in general.
-
16. Re: releasing 3.2.Beta1
Hm, so I guess to work around it I need to examine the start node and determine whether there is a task associated with it. Seems like there should be a better way...
-
17. Re: releasing 3.2.Beta1
i just added an if-then-else in the code with a check for the existence of a task in the start-state.
all tests succeed. so now when there is no start task, createStartTaskInstance will return null in case there is no start task.
just checked it in. hopefully it is still in time for you to check it out -
18. Re: releasing 3.2.Beta1
Ok, with that fix I've done the following:
- The "new tasks" list is now a list of created tasks, not assigned tasks. This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.
- Fixed another NPE that happens on task instance view if there is no forms.xml.
- Added a "signal" button to the token list to allow a token to be moved along transitions.
I did run across a new problem. Some of the nodes that I create in the GPD have a width and height of -1 in gpd.xml, making the process diagram fail to work properly. Also, I have one more screen to make tonight that links to a new process instance in the case where a process definition is started which contains an initial wait state, but no tasks (right now there's no direct link to take you to the newly created process instance, as I realized in today's testing session).
Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case. -
19. Re: releasing 3.2.Beta1
Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case.
In this situation the client should signal the token via the api, i.e, the web app should signal the token. -
20. Re: releasing 3.2.Beta1
"jeffdelong" wrote:
Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case.
In this situation the client should signal the token via the api, i.e, the web app should signal the token.
In this case I have to establish the criteria for signalling the token. The start node might have multiple transitions, so I presume that I'd only signal if there is a default leaving transition (node.getDefaultLeavingTransition() != null). The main thing that concerns me though is, how do we know that the start token isn't intended to be a wait state, for whatever reason. In a normal Node, we rely on the execute() method to determine whether a transition is immediately taken or the Node is a wait state. However, since StartState's execute() is an illegal operation (in other words, the Token is just pointed at the Node without calling execute()), you never "arrive" in the start state; therefore the start state node never has an opportunity to establish its intention.
My personal opinion is that the start state should be executed like any other node, but of course I'm probably missing critical background on the issue. :-)
I think the best I can do with what we've got now, is something like this: if (no start task instance && initial node has a default leaving transition) { signal the token along the default transition }
Make sense? -
21. Re: releasing 3.2.Beta1
Ok, now if a process is started with no initial tasks, the user is sent to the correct process instance with a link, rather than being left wherever they were beforehand.
Last thing to do is to implement the auto-signalling as described above... -
-
23. Re: releasing 3.2.Beta1
"david" wrote:
I did run across a new problem. Some of the nodes that I create in the GPD have a width and height of -1 in gpd.xml, making the process diagram fail to work properly.
This is a known initialization problem. It can be worked around by moving the node a little bit on the canvas after it was added. Not a real good solution, but this will be solved in the 3.1 branch of the GPD.
Regards,
Koen -
24. Re: releasing 3.2.Beta1
"david.lloyd@jboss.com" wrote:
- The "new tasks" list is now a list of created tasks, not assigned tasks. This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.
i would call that list the "Unassigned tasks". it's a good idea. also you could make the initiator responsible for the assignment in case a task is created without an assignment."david.lloyd@jboss.com" wrote:
Also one question I have is this: when a process starts that does not have a task on the start state (and therefore, I presume, no reason to wait), should the token automatically proceed out of the start state? Right now the user must signal the token manually in this case.
wether or not the process should signal automatic with the start should be in the process definition. not in the webapp. currently there is no such feature in which you can specify that the default transition has to be taken automatically when a process instance is created.
for functional behaviour i don't think this is really necessary. you can always add an action on event process-start. then a developer could always turn the start-state into a wait state. but of course, this seriously limits the modeling freedom.
another way to solve this is to do the same as in SEAM page flow. there you can specify an attribute initial="myStartNode" in the process-definition. that way, you are not forced to have a start-state as the initial node in your process definition. i think this would be the most elegant solution. -
25. Re: releasing 3.2.Beta1
"tom.baeyens@jboss.com" wrote:
"david.lloyd@jboss.com" wrote:
- The "new tasks" list is now a list of created tasks, not assigned tasks. This should fix the problem that no tasks are being presented on the screen when a process is started having a start task and no swimlanes or assignment magic.
i would call that list the "Unassigned tasks". it's a good idea. also you could make the initiator responsible for the assignment in case a task is created without an assignment.
i forgot to mention that this has no real priority as this is navigation and the navigation will probably be shaken pretty significantly when the se's give their feedback.
also i just saw a potential minor problem with this. i just started the websale process. and as the feedback on starting a process instance, i got the 'New Tasks Created' screen with in the table, '(nobody)' in the 'Assigned To' column. When i clicked the task, it appears to be assigned to ernie (the initiator) as to be expected from the process definition. So after starting a new websale process, the user should have been navigated to the task screen instead of the 'New Tasks Created' screen, i think. -
26. Re: releasing 3.2.Beta1
just noticed another problem with the webapp. the user task list shows tasks for all users. that is not good. the user task list should only show the tasks that are assigned to the authenticated user. also the column 'Assigned To' should then be removed.
later, we should concentrate on searching tasks with various criteria. so that a manager can keep track and intervene with tasks for his subordinates. this also requires a better authorization mechanism then the one we currently have. -
27. Re: releasing 3.2.Beta1
functionally the webapp is MORE THEN RICH ENGOUGH for the 3.2 release. Good work, David !
so for the 3.2.Beta1 release, please focus on getting these last issues resolved. this has highest priority. i'll go through the web console some more and summarize the high prio issues to be resolved for 3.2.Beta1
then we should collect feedback from SE's and other people on the navigation. i think that with a few minor enhancements we are pretty close to what i consider a professional and great console. -
28. Re: releasing 3.2.Beta1
summary: high priority for 3.2.Beta1
a) make sure that the user task list only displays tasks for which the current authenticated user is the actorId. (the group task list should display all the tasks for which the current authenticated actor is somewhere in the list of pooled actor ids. also note that the pooled actors could contain the group id to which a user belongs)
The group task stuff is just for your info. In case there would be a problem with it, that doesn't have to be solved in 3.2.Beta1
b) starting the websale process does not navigate to the task form. somehow the web console thinks that the task is unassigned.
David, could you fix these two problems asap and post feedback here ? thanks. -
29. Re: releasing 3.2.Beta1
"tom.baeyens@jboss.com" wrote:
also i just saw a potential minor problem with this. i just started the websale process. and as the feedback on starting a process instance, i got the 'New Tasks Created' screen with in the table, '(nobody)' in the 'Assigned To' column. When i clicked the task, it appears to be assigned to ernie (the initiator) as to be expected from the process definition.
This is an oversight on my part - I'm pulling the assigned actor from the TaskCreateLog entry. Apparently the actor ID is always null here (the actor ID isn't assigned until the subsequent TaskAssignLog entry). I'll just pull the actor ID from the task itself, that way it won't be wrong.
As far as redirecting to the task form: That's a navigation bit that I've left undone. In my estimation, users probably want to go to the task form directly, but managers may want to see the task list to know that there are (or are not) other tasks for other users. When the SEs give their feedback, I'll have to assemble a list of criteria that I use to choose how navigation goes.
As far as the tasklist goes: what I've implemented isn't really a user task list, it's really a "manager" task list , with all tasks for all users being listed. This is something else that will be changed I expect. I think that in the end, both variations will exist, but one will be chosen based upon user role; or perhaps the manager version will be in a separate set of screens and the manager will have access to both. I can easily split it out though.
The group task list still needs more testing.