-
15. Re: new simplified menu structure
changing the db schema to split the jbpm_processdefinition table in 2 is too complicated, i think.
but we could add a column ISLATEST_ to the process definition table that we maintain manually during deployment.
is that a good idea ? -
16. Re: new simplified menu structure
"tom.baeyens@jboss.com" wrote:
changing the db schema to split the jbpm_processdefinition table in 2 is too complicated, i think.
but we could add a column ISLATEST_ to the process definition table that we maintain manually during deployment.
is that a good idea ?
Yes that would work around the problem for now. When I speak of changing the DB schema to split the tables, I'm suggesting that as something to do in 4.x. -
17. Re: new simplified menu structure
The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task".
The "End" "Cancel" and "Save" are rather confusing, we changed those to be specfic action names so users would know what they were doing, like "Submit Request" and such.
And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button. -
18. Re: new simplified menu structure
"falazar" wrote:
The "End Task" is not terminology that is defined by the web console. The caption of each of the transition buttons is determined by the name of the corresponding transition. In this case, the "websale" example process happens to have transitions named "End Task".
The "End" "Cancel" and "Save" are rather confusing, we changed those to be specfic action names so users would know what they were doing, like "Submit Request" and such.
+1. So we should give some thought on how the user can specify button names and link them to transition names. By default, the transition names are chosen, but the user should be able to override these. If no transition name is specified and no button name is given, we can't do anything else except come up with a silly generic name."falazar" wrote:
And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button.
good point. that button got me fooled too. since there is a task.cancel method, i thougt it was cancelling the task. "Back to Inbox" is indeed better -
19. Re: new simplified menu structure
"tom.baeyens@jboss.com" wrote:
+1. So we should give some thought on how the user can specify button names and link them to transition names. By default, the transition names are chosen, but the user should be able to override these. If no transition name is specified and no button name is given, we can't do anything else except come up with a silly generic name.
I can add an attribute to the transitionButton component for an optional caption. If the caption is not present, use the transition name. If the transition is unnamed, then I guess just "Transition ID 1234" is the best we can do..."tom.baeyens@jboss.com" wrote:
"falazar" wrote:
And the "Cancel" does not actually cancel the task or the process, so it is very ambigously named, we changed it to "Go back to inbox" and added a Cancel Request transition button.
good point. that button got me fooled too. since there is a task.cancel method, i thougt it was cancelling the task. "Back to Inbox" is indeed better
Hmmm, upon reflection I think that a cancel task button is a lot more useful than the current cancel button is - what if I change this button to "Cancel Task" which calls the .cancel() method on the task instance, and just drop the idea of the original cancel button? Especially in light of the new navigation structure. -
20. Re: new simplified menu structure
I'm not in favour of end-users being able to realy cancel the task. An admin/manager might and even then only if the process is not hindered/disrupted in any way.
Regarding the name issue... I'm still in favour of requireing the name to be filled in the pd.....
besides that I also have an interesting one ;-) : use the description from the jpdl file as a tooltip -
21. Re: new simplified menu structure
"kukeltje" wrote:
I'm not in favour of end-users being able to realy cancel the task. An admin/manager might and even then only if the process is not hindered/disrupted in any way.
Point taken - however, consider this. The task form designer (person) may elect to simply leave that button off of the task forms. Or, he/she may put the button on, but use rendered="#{some custom EL}" to make it only visible to certain classes of users (admins for example). If the component exists, it can be used or not used. If it doesn't exist, it may only be not used. :-)"kukeltje" wrote:
Regarding the name issue... I'm still in favour of requireing the name to be filled in the pd.....
besides that I also have an interesting one ;-) : use the description from the jpdl file as a tooltip
Good idea - I can use the description by default, or allow the designer to override it in the standard JSF way using the title attribute. -
22. Re: new simplified menu structure
+1 on the rendering (or not) of the cancel button. But still... if a task has to be cancelled, in many case this should influence the flow and I therefor would model this into the workflow and have a 'cancel' transition etc... sometimes only for admins or so. Realy cancelling the task could lead to missing information or so...
All these consequences have to be documented realy good.