Thinking about transition attrs

[brittm]

The process patch thread got me thinking about some things I've been wanting to see in Transition configuration.

1) Is anything in the works to allow a process designer to suggest to the UI that a user be asked to "confirm" a particular transition? For instance, when completing a task, one option might be 'done' while the other option is 'cancel'. If the user selects 'cancel', the process designer may want to suggest that he user be asked to confirm that choice.
Something like

<transition name='...' to='...' confirm='true'/>

2) Is anything coming up that would allow the process designer to suggest to the UI that a transition should be restricted to administrative use? For instance, transitions that you would like to be available to application adminsitrators or administrative tools, but not available to the typical user--I might not want a typical user to revisit a node handling integration 20 times in one hour, but I might want an admin to be able to retry it after the problem has been solved--same thing for some types of cancellation.
Something like

<transition name='...' to='...' restricted='true'/>

or refer to a UI's roll based system with

<transition name='...' to='...' role='admin'/>

I know there have be plenty of words put out discussing where certain types of configuration ought to go. Thoughts?

-Britt

[tom.baeyens]

"brittm" wrote:
The process patch thread got me thinking about some things I've been wanting to see in Transition configuration.

1) Is anything in the works to allow a process designer to suggest to the UI that a user be asked to "confirm" a particular transition? For instance, when completing a task, one option might be 'done' while the other option is 'cancel'. If the user selects 'cancel', the process designer may want to suggest that he user be asked to confirm that choice.
Something like

<transition name='...' to='...' confirm='true'/>

that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document. that is where you could reference java script or a new component.

i don't think this info should be added to the process definition itself.

"brittm" wrote:

2) Is anything coming up that would allow the process designer to suggest to the UI that a transition should be restricted to administrative use? For instance, transitions that you would like to be available to application adminsitrators or administrative tools, but not available to the typical user--I might not want a typical user to revisit a node handling integration 20 times in one hour, but I might want an admin to be able to retry it after the problem has been solved--same thing for some types of cancellation.
Something like

<transition name='...' to='...' restricted='true'/>

or refer to a UI's roll based system with

<transition name='...' to='...' role='admin'/>

I know there have be plenty of words put out discussing where certain types of configuration ought to go. Thoughts?

-Britt

same here. to implement this, we should be looking at configuring the task form transition button in some way. probably this is already possible in facelets with the use of a simple if tag around the transition button.

[kukeltje]

that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document. that is where you could reference java script or a new component.

i don't think this info should be added to the process definition itself.

+1

same here.

I do not agree here. The functionality described here can be realized with conditional transitions in combination with EL (toch?)

[brittm]

re: "confirm='true'"

that is UI. the task form ui only can do so much. we can keep adding features till it is as rich as JSF+Facelets+RichFaces... if it would be added, it should be done in the Facelets form document.

The problem here is that it is not up to the UI designer to determine what should require a confirmation. This is the domain of business analyst/process designer.

We have nearly 200 tasks over more than 20 processes (and we're not done). We work in a rapidly evolving environment and need a way to tell the UI developer which transitions need a confirmation based on their impact on the process--some way other than handing him a spreadsheet of 100+ process/node/transition combinations to keep track of.

To keep things sane we'll either have to break with schema valid jpdl, or use a naming convention--something like if the transition name starts with a "+", don't display the "+" and require a confirmation.

The same thing is true with restricted access. We're already blocking visibility of transitions like 'administrative cancel' and 'retry integration' by prefixing them with an "_". Its a way to say "admin only" without having to know how the UIs define that role.

But parsing transition names to figure out which type they are is a poor solution. Sure, we can build our own configuration files/tables to sit along side of jBPM, but then we're just repeating 'process/node/transition' mappings over and over, and are operating outside the scope of versioning.

Both of these items are configuration flags that specify how a transition should behave, not how that behavior should be implemented.

[kukeltje]

Britt, look at my post. The conditional transitions are already possible.

The confirmation thing should imo be added to the GPD so the 'wizard' can add it to the forms.

Ronald

[camunda]

I think these informations belong to user interface. I understand you problem Britt, but adding it to the process definition is not a clean way.

In our own Swing GUI framework we have exactly the same, but configured in the GUI configuration. There you are free to configure what you want and also can make different configurations, for example for different user groups:

<tk4jbpm>
...
<state name="consignment urgent"
start-class="com.camunda.ccs.process.order.swing.CheckOrderDataComponent">
 <transition name="cancel order" confirm="true" />
</state>
...
</tk4jbpm>

[brittm]

Ronald,

I'm not sure how useful an EL would be for setting restriction. I'd need some kind of UI identification switch or the user's roles in scope to compare with. (Would SEAM make these things more readily available to the process execution?) (Or have I missed some funtionality that allows container roles to be pulled into the execution context?)

Some things to consider:
* This is a big organization. We have an LDAP infrasfructure for managing users and groups--jBPM's identity component is not an option. I think this would be a typical scenario in most enterprises.

* Our UI is already built and extends far beyond what can be generated by the GPD (and probably will for a very long time). Not to mention, that when regularly using all of jpdl's capabilities the current GPD becomes more of a hinderance than a help. (Ok, I confess it's been a while since I've looked at it :-)

* Bernd, we have scores of tasks that are managed by our system but that are not yet performed in our system, if they ever will be. That means no custom screens (and no additional configurations) are created for over 100 tasks--users just claim a task and take an available transition. This scenario is typical for a large company that is implementing a workflow system to manage process flows across several existing IT systems. Requiring the UI to have proper configuration for every item is a significant barrier to entry when it comes to getting lots of processes and tasks on the system in a relatively short amount of time.

I'm really not trying to push a particular solution, but I am trying to point out an area of pain--an area in which a few small compromises (or as yet unseen solutions) could go a LONG way toward helping the largest corporations see a rapid deployment and return on investment. Once the existing processes have been defined, it comes down to this: I can set a few flags and deploy processes acoss the entire company under a generic UI, or the company can wait until I've mapped over and built up a UI for 200 tasks. In our case, we've had to hack the first solution, because there is no way the company would have let us do the latter one.

Thanks,
Britt

[kukeltje]

I'm not sure how useful an EL would be for setting restriction.

By returning a boolean true or false for displaying it or not

I'd need some kind of UI identification switch or the user's roles in scope to compare with. (Would SEAM make these things more readily available to the process execution?) (Or have I missed some funtionality that allows container roles to be pulled into the execution context?)

Seam: yes, or an extension in jbpm.

Some things to consider:
* This is a big organization. We have an LDAP infrasfructure for managing users and groups--jBPM's identity component is not an option.
I think this would be a typical scenario in most enterprises.

Same here.... shall we both work on an ldap identity component?

* Our UI is already built and extends far beyond what can be generated by the GPD (and probably will for a very long time).

Same here... GPD based generated forms is nice in some cases, not others. Therefor I want the processdefinition to be namespace aware. That way you can add elements/attributes to the pd and e.g. use an xslt to generate jsf forms (or something else)

Not to mention, that when regularly using all of jpdl's capabilities the current GPD becomes more of a hinderance than a help. (Ok, I confess it's been a while since I've looked at it :-)

For the forms that is currently true... dropdowns, selectitems etc... ever looked at xforms?

* Bernd, we have scores of tasks that are managed by our system but that are not yet performed in our system, if they ever will be. That means no custom screens (and no additional configurations) are created for over 100 tasks--users just claim a task and take an available transition. This scenario is typical for a large company that is implementing a workflow system to manage process flows across several existing IT systems. Requiring the UI to have proper configuration for every item is a significant barrier to entry when it comes to getting lots of processes and tasks on the system in a relatively short amount of time.

No comment (I simply have none ;-))

I'm really not trying to push a particular solution, but I am trying to point out an area of pain--an area in which a few small compromises (or as yet unseen solutions) could go a LONG way toward helping the largest corporations see a rapid deployment and return on investment. Once the existing processes have been defined, it comes down to this: I can set a few flags and deploy processes acoss the entire company under a generic UI, or the company can wait until I've mapped over and built up a UI for 200 tasks. In our case, we've had to hack the first solution, because there is no way the company would have let us do the latter one.

What about the namespace extensions? The GPD should leave those alone .... that would help a lot.... (in our case)

[brittm]

By returning a boolean true or false for displaying it or not

The problem with the EL (afaik) is that it can't call a method, such that evaluating "isUserInRole()" will not work, nor will Set.contains(), even if we could get the appropriate objects in scope.

We would need to ensure that EL has access to a complete listing of the user's roles in the form of a Map with [roleName:true] as entries. Then the EL {userRoles["admin"]} would return 'true' if the user is in the 'admin' role and would return null if not.

This is mighty ugly (but it would work). Though we still would need to figure out a way to produce the roles map and make it available. I'm just brainstorming--does anyone have a clearer idea?

What about the namespace extensions?

Sounds like an option.

[kukeltje]

The userRoles is imo not even a dirty solution. It is what I meant with an extension to jbpm (maybe the identity expression evaluation can be used for this?)

I had a small look and transition accepts a condition element, which (afaik) currently only uses an expression attribute to be evaluated. Maybe adding a tag to the decision would help, so more complex things can be used, including calling out to a businessrule.

[tom.baeyens]

brittm, i think that method binding *is* supported in our current implementation. i remember i tweaked commons-el to check for property-getters, fields and methods.

but the downside is that this feature might be removed as we are probably going to standardize on the jboss-el implementation. that one supports even parameter binding in methods, but you have to choose wether you do a value binding or a method binding upfront. which means that you'll have to use different tags for method binding as for value binding in the language.

for adding the ui-stuff like confirm="true" to the process, i'm not that strict in separating process and UI things. i believe there can be some overlap for convenience. however we are very careful before we implement things that we don't consider crucial. as every piece of code that we include requires maintenance. and if this maintenance becomes too big for the benefits, combined with the load we can handle, it might be that your feature just gets removed. that is worse for you. so we are very reluctant to adopt new features, not in the core target of the project and if there is a chance that we might not be able to sustain the maintenance.

[estaub]

brittm,

I think you need to look for a different place, under control of your business analyst/process-designer, to keep the particular UI-specification metadata that you need.

The only place I see to do this cleanly in the process definition per se is in the configuration of custom actionHandlers. If you can see how to "reach" there from your UI, then great!

Otherwise, I think you'll need an external XML config file or similar, with a tiny POJO or EJB for accessing it from the UI. Frankly, I'd prefer this solution anyway, because you can see the "crosscut" confirmation policy all in one place. But your mileage may differ.

-Ed Staub

[kukeltje]

Personally I would not abuse actionhandlers (that is what it seams to me ed), and would not use an external xml file. I would use namespaces to extend the pd.xml and you have access to that runtime)

[kukeltje]

Additional info:

Extending the pd.xml with custom namespace attributes and elements should not require extending the node/task/... objects and the persistency. You just access it through the xml file (cashing it after it is parsed is advisable)

[kukeltje]

that should be caching ;-)