[jboss-dev-forums] [Design of JBoss jBPM] - Re: task forms

david.lloyd@jboss.com do-not-reply at jboss.com
Thu May 31 10:29:17 EDT 2007


"tom.baeyens at jboss.com" wrote : there are 3 target audiences: process participants, managers and administrators
  | 
  | administrators is the most important one to go into production.  that kind fo functionality is what we have been lacking till now.    that doesn't mean that we should present the task forms to admins.  
  | 
  | if a user only has the process participant role, he/she should not see the admin stuff and you should see an end user webapp.  so for the process participants, the web app should be designed for end users to process their tasks.

I believe that the requirements for participants/managers versus administrators are too different to unify into a single application.  I also believe that any application we develop that is targeted towards participants/managers would at best be useful as a demo... I don't think that many organizations would want to use that application as-is.  This is based on actual discussions with our sales engineers who deal with people using the product.  If such an application is needed, it ought to be developed as a separate, simple jbpm-demo webapp that just provides the functions that were present in the prior console.  Though by updating that application to use the jbpm4jsf component libraries, it could be greatly simplified.

That said, the current console has very fine-tunable security.  There are no hardcoded roles like "participant" for example; everything is configurable.  Look at access.properties to see how to control access to just about any part of the application.  You can remove entire sections of the application.

For example, if an organization decides not to use the identity component, they can just block it in access.properties and the whole section disappears.

Making actual action navigation depend on role is much more complicated.  In addition it makes maintainability much more difficult because the multiple possible outcomes complicates testing exponentially.  In my opinion, this kind of variable navigation is an indication that the application is trying to solve too many problems.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4050184#4050184

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4050184



More information about the jboss-dev-forums mailing list