2 Replies Latest reply on Jun 19, 2006 7:55 AM by zudduz

    ACL tied Transitions

    zudduz

      My brief research into JBPM has not revealed a clear way to tie ACL's to the leaving transitions of a wait-state node.

      An appropriate use of such a process would be for a defect system where when a defect is at the "in progress" node the assigned developer could declare it in for build or the originating QA could realize that it was no longer valid and kill the defect. One wouldn't want developers able to kill defects or QA's do declare defects in for build.

      I don't see a clean way to do this. This information seems to be strongly tied to the process and I would contend that it should be in the process definition.

      My best Idea is to extend org.jbpm.graph.def.Node and create an AclNode class. This seems to me that it would get real complicated real quick, especially since I haven't been able to find documentation for doing this yet. This Acl node would require some way of attaching to the ACL engine. It's available transitions returned would need to be specific to a given permission or set of permissions. Also, it should only provide legal transitions which would require it to know no not only the requested transition to leave upon but also the set of permissions available to the initiator.

      With all those requirements that seem to change the Api it's starting to look as though this AclNode isn't really a node at all. Perhaps it's only a graph element. But the higher I climb the inheritance tree the more complicated all of this gets (I assume).

      Advice and creative solutions are much appreciated. I am happy to elaborate on any point if someone finds part of this confusing.

        • 1. Re: ACL tied Transitions
          kukeltje

          First, it is a clearly stated issue, so no elaboration needed.

          Creative solution:

          - make one task node (in progress)
          - make two tasks in there, one for the developer, one for the QA
          - create two screens, one for the developer, one for the QA
          - have each screen have just a subset of the transitions

          hey, maybe you should not even use one state, but a fork, parallel task nodes and a join. Mixing up the higher level state of a case and indivual 'task' can make things more complex than they realy need to be.

          Cancelling things in a process is often needed in multiple places. I personally do not model these as state/task, just separate pages, more like a case manager. The same is (imo) true for reassignment things. Only if an assignment step is explicit, we put it in the model. Otherwise it is a separate action on

          • 2. Re: ACL tied Transitions
            zudduz

            Thanks for your prompt response. I believe that this is what I was looking for.