6 Replies Latest reply on Jun 16, 2009 5:38 AM by jeff.yuchang

    GroupId or (groupName & GroupType)

    jeff.yuchang

      Just found out that we've used the groupId in the jPDL file, for example, in the TaskCandidateTest.class, we've had following jpdl file.

      <?xml version="1.0" encoding="UTF-8"?>
      
      <process name="TaskCandidates">
      
       <start g="20,20,48,48">
       <transition to="review" />
       </start>
      
       <task name="review"
       candidate-groups="jbpid_group_id_._._unit_._._sales-dept"
       g="96,16,127,52">
      
       <transition to="wait" />
       </task>
      
       <state name="wait" g="255,16,88,52"/>
      
      </process>
      


      For the candiate-groups, we need to specify the groupId, because the groupId is identity component specific, which means it might differ in different identity implementation. So I don't think it is good to use the id in this case.

      Because in the process of doing jboss identity integration, I've found if I want to make the test suite passed, I need to update the jpdl file. And if I want to switch to use the jbpm-built-in identity, then need to update the jpdl file again due to the change of groupId difference.

      My suggestion is: for groups, we used:
      candidate-groups = "groupName/groupType"
      

      if the groupType == null or a default jBPM groupType (unit), it can be just specified as only groupName, like:
      candidate-groups="groupName"
      


      While, for the users, we've used username as the value.

      user="username"
      


      Got any thoughts??

      thanks
      Jeff

        • 1. Re: GroupId or (groupName & GroupType)
          tom.baeyens

          "jbpid_group_id_._._unit_._._sales-dept" is a very nasty id that you generate.

          so the real point is actually: shouldn't we switch to user-provided id's for the groups as well. just like we do with the users ?

          what was the reason that we didn't do that ?

          • 2. Re: GroupId or (groupName & GroupType)
            jeff.yuchang

             

            "tom.baeyens@jboss.com" wrote:
            "jbpid_group_id_._._unit_._._sales-dept" is a very nasty id that you generate.

            so the real point is actually: shouldn't we switch to user-provided id's for the groups as well. just like we do with the users ?

            what was the reason that we didn't do that ?


            I think we can have an approach to this issue.

            we will use what it uses for groupId, candidate-group now. but we need to document the format for this groupId:

            it is:

            String groupId = groupType != null ? groupType + "." + groupName : groupName;
            


            in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.

            In this case, we don't need to make any changes, the only one thing is just to document it?

            What do you think?

            -Jeff



            • 3. Re: GroupId or (groupName & GroupType)
              kukeltje

               

              "jeff.yuchang" wrote:

              in this case, the groupId format is maintained by jBPM, and not identity component dependent. so if users/developers switch to other identity provider, they must conform this rule.

              In this case, we don't need to make any changes, the only one thing is just to document it?

              What do you think?


              I don't think large (or even small) companies are going to switch to adapting their IDM (or more complex IAM systems) to conform to this jBPM requirement. No way. A real life example:

              In an LDAP we used, the groupname was the CN, the real id is the DN, which was composed of the CN, O and C filed. How could this be adapted to the jBPM id format. In addition.

              In another situation there was an additional OU in between which could also be used as a group when the users below the OU are seen as part of the group. How would the 'id' fit in here?

              Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations.

              • 4. Re: GroupId or (groupName & GroupType)
                jbarrez

                +1

                I don't think large (or even small) companies are going to switch to adapting their IDM (or more complex IAM systems) to conform to this jBPM requirement.


                I agree. Users have the strangest IDM mappings in place, I've seen my share of strange, legacy stuff.

                By not constraining the assignment strings in the jpdl file, people can do whatever they want, which is the best solution, imo.

                • 5. Re: GroupId or (groupName & GroupType)
                  bdaw

                  In JBoss IDM when you plug LDAP you point groupType to a specific tree part. Then you would refer to configured groupType and simply use the CN part as groupID. Id needs to be unique in scope of groupType so this fits.

                  I think jbpm could allow non constrained ids and just force composite ids for idm integration. then in situation when you plag few different identity stores and map group types to them you need to have some way to discover where they belong anyway. And groupType in composite key allows this.

                  • 6. Re: GroupId or (groupName & GroupType)
                    jeff.yuchang

                     

                    "kukeltje" wrote:


                    Would be nice if this is fully left to the users if they choose to put e.g. a DN in the assignment or an LDAP filter or maybe even an SQL statement, so consider it as a string and do not impose any rules on the formatting. For the JBoss IDM implementation there are the 'rules' but that is just for this implementation and should not impose any constraints on possible other implementations.


                    Thanks for the info, yes, this is a totally valid point.. now I see the bad result of imposing constraints on the groupId.

                    ;-)

                    thanks
                    Jeff