June 2009 - jbpm-dev - Jboss List Archives

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by jbarrez

+1 anonymous wrote : 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237820#4237820 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237820

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237819#4237819 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237819

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by jeff.yuchang

"tom.baeyens(a)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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237811#4237811 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237811

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: GroupId or (groupName & GroupType)

by tom.baeyens＠jboss.com

"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 ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237799#4237799 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237799

15 years, 5 months

1
0
0 / 0

Hudson build is back to normal: jbpm4-jboss » hsqldb,5.0.0.GA,java16_default,dev45 #43

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jbpm4-jboss/./DATABASE=hsqldb,JBOSS...

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - GroupId or (groupName & GroupType)

by 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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237698#4237698 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237698

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 4 BusinessCalendar

by tom.baeyens＠jboss.com

created https://jira.jboss.org/jira/browse/JBPM-2334 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237559#4237559 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237559

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Fluent programming on Commands

by tom.baeyens＠jboss.com

i don't think commands should be exposed in the api. only the methods in the service interfaces. in that case the fluentness of the comand api becomes an internal impl detail. ok with the fluent api. but don't see the need to spend time on it as it's an impl detail. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237558#4237558 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237558

15 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 4 BusinessCalendar

by camunda

+1! I remember me proposing something like that in Antwerp ("making the business calendar implementation pluggable") :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237534#4237534 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4237534

15 years, 5 months

1
0
0 / 0

Hudson build is back to normal: jbpm4-jboss » postgresql,5.0.1.GA,java15_default,dev45 #42

by jboss-qa-internal＠redhat.com

See http://hudson.qa.jboss.com/hudson/job/jbpm4-jboss/./DATABASE=postgresql,J...

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jbpm-dev June 2009