4 Replies Latest reply on May 31, 2007 5:39 PM by kukeltje

    task forms

    tom.baeyens

      afiact, task forms seem to be broken for me. can you check if you can reproduce that ?

      also i wanted to check if i'm using the right way to start processes. in the processes list i click start (which i think is good). but then i see the list of tasks and i have to do 2 more clicks to navigate to the task form.

      after the process start link is clicked, i think it would be better to navigate directly to the task form if there is one. what do you think ?

        • 1. Re: task forms
          dmlloyd

          I by "broken" you mean "I didn't do that yet", yeah. It's not a finished product. I still have a good 8 or 9 items on my todo list yet.

          No, I am against navigating to the task form. This application is not designed for end users to process their tasks; it is for the administration of a jBPM installation.

          • 2. Re: task forms
            tom.baeyens

             

            "david.lloyd@jboss.com" wrote:
            I by "broken" you mean "I didn't do that yet", yeah. It's not a finished product. I still have a good 8 or 9 items on my todo list yet.


            with broken i mean that the content page remains empty when i click the task form link.

            "david.lloyd@jboss.com" wrote:
            No, I am against navigating to the task form. This application is not designed for end users to process their tasks; it is for the administration of a jBPM installation.


            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.

            if you are an admin, you should have all admin features and functionalities available. it should be based on the servlet security roles.

            as for the navigation, we should strive for 1 overall webapp + navigations so that based on the roles, some parts/columns/actions are just not displayed.



            • 3. Re: task forms
              dmlloyd

               

              "tom.baeyens@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.


              • 4. Re: task forms
                kukeltje

                 

                I also believe that any application we develop that is targeted towards participants/managers would at best be useful as a demo...
                I agree, but in the demo, you present it to management and they are very 'picky' on these simple kinds of things, so if it is possible (by just detecting the kind of role) to either presenting the form or a tasklist, we should do that. If the app becomes to complicated, we maybe should deploy to apps? One just for users and one for more stuff?