nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

User Form Type does not show users when using LDAP

b_schnarr

Maybe, I did something wrong. When I use local users, the user form type works well and I can select my assignee. Now I connected the Explorer to an LDAP. The integration works well but the user form type does not show any users anymore.

Did I something wrong or is this a bug?

Thank you
Ben

Find more posts tagged with

Comments

b_schnarr

I tried it with a fresh installation of activiti 5.14 with LDAP. But no chance, the user form type doesn´t show any users. But this is a very fundamental function. Therefore: How can I assign tasks to users in the Activiti Explorer when using LDAP?

I appreciate all kind of help. It is very urgent. Thank you very much and best regards
Ben

tombo

Yes, this issue is present from version 5.13 and up. Using integration with any LDAP, search doesn’t find any users for assignment. I was unable to determine the cause.

Regards,
Boris

frederikherema1

Activiti explorer is a demo-app. UserFormType is an example on how to create custom renderers in the explorer app. This widget is based on a user-cache inside the explorer-app. Since the LDAP-implementation doesn't allow to list all users to fill that cache, the user-selection doesn't work. You'll have to create a custom widget/rendered that uses the raw LDAP to query against…

b_schnarr

Is it on the roadmap to make the User Form Type work with LDAP? It is IMHO a very important feature for the most companies.

b_schnarr

So I must define a LDAP Query which fetches all available users so that the user form type can use those IDs. Could you give me a hint how I could realize this? Which classes do I have to investigate and extend?

Thank you very much
Ben

frederikherema1

I just looked at the source, and it's not using a cache but the IdentityService (I guess it has been refactored since I last looked at it):

org.activiti.explorer.ui.custom.SelectUsersPopupWindow

<br> protected void searchPeople(String searchText) {<br>&nbsp;&nbsp;&nbsp; if (searchText.length() >= 2) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; matchingUsersTable.removeAllItems();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; List<User> results = ProcessEngines.getDefaultProcessEngine()<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .getIdentityService()<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .createUserQuery()<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .userFullNameLike("%" + searchText + "%")<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .list();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (User user : results) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (!multiSelect || !selectedUsersTable.containsId(user.getId())) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (ignoredUserIds == null || !ignoredUserIds.contains(user.getId())) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; addMatchingUser(user.getId(), user.getFirstName() + " " + user.getLastName());<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp; }<br>

The default implementation of the LDAP supports the getFullNameLike(). Maybe the %-signs added around it causes the issue. Debug a bit in those classes to see what is causing this in your case…

b_schnarr

Thank you very much for your investigation. You wrote :"The default implementation of the LDAP supports the getFullNameLike()." Does that mean that actually, it SHOULD work with LDAP, too?

b_schnarr

One step further: I removed the %-signs and builded again. Now, when I type in the first 2 or 3 letters of the assignee I want to search for, I get the error: Warning: null
Look at this picture: https://www.dropbox.com/s/xdr1js0tozksjxn/ldap%202.png

When I continue to type more letters, he finds the users from the LDAP (https://www.dropbox.com/s/9d7qdvhag5xvf1g/ldap_user_form_type.png). I did nothing more. Just removed the %-signs. The method now looks like that:
<code>
List<User> results = ProcessEngines.getDefaultProcessEngine()
              .getIdentityService()
              .createUserQuery()
              .userFullNameLike(searchText)
              .list();
</code>

Tomcat logs say:

<code>
com.vaadin.event.ListenerMethod$MethodException: Invocation of method textChange in org.activiti.explorer.ui.custom.SelectUsersPopupWindow$1 failed.
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:530)
at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:164)
at com.vaadin.ui.AbstractComponent.fireEvent(AbstractComponent.java:1219)
at com.vaadin.ui.AbstractTextField.firePendingTextChangeEvent(AbstractTextField.java:470)
at com.vaadin.ui.AbstractTextField.changeVariables(AbstractTextField.java:251)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.changeVariables(AbstractCommunicationManager.java:1460)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariableBurst(AbstractCommunicationManager.java:1404)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1329)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:761)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:325)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.activiti.explorer.filter.ExplorerFilter.doFilter(ExplorerFilter.java:44)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at org.activiti.ldap.LDAPUserManager.mapSearchResultToUser(LDAPUserManager.java:162)
at org.activiti.ldap.LDAPUserManager$2.executeInContext(LDAPUserManager.java:136)
at org.activiti.ldap.LDAPUserManager$2.executeInContext(LDAPUserManager.java:123)
at org.activiti.ldap.LDAPTemplate.execute(LDAPTemplate.java:44)
at org.activiti.ldap.LDAPUserManager.findUserByQueryCriteria(LDAPUserManager.java:123)
at org.activiti.engine.impl.UserQueryImpl.executeList(UserQueryImpl.java:163)
at org.activiti.engine.impl.AbstractQuery.execute(AbstractQuery.java:139)
at org.activiti.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:24)
at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:57)
at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:47)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:131)
at org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:45)
at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:31)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:40)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:35)
at org.activiti.engine.impl.AbstractQuery.list(AbstractQuery.java:113)
at org.activiti.explorer.ui.custom.SelectUsersPopupWindow.searchPeople(SelectUsersPopupWindow.java:180)
at org.activiti.explorer.ui.custom.SelectUsersPopupWindow$1.textChange(SelectUsersPopupWindow.java:142)
at sun.reflect.GeneratedMethodAccessor442.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:510)
… 33 more

</code>

I recognized the following. When I type in random letters like fgfgfgdcvbjnh, I correctly get no user and no error. When I type in the first two letters of kermit (ke) or gonzo (go), I get the mentioned error. Very strange

Thanks for your answers

jbarrez

that extra null check wouldn't hurt.

But if something causes a null pointer 'sometimes', that doesn't sound right. Would be better if it is consistent 😉

b_schnarr

Ok, my fault. Sometimes is the wrong word. Those errors always occur then you try to search user. E.g. when you type in the first 2 letters of kermit, you will get this error. even though there is a LDAP User kermit. What do you suggest? The user form type works fine with local users. All I did is to remove the %-signs. Now, the exceptions occur.

b_schnarr

This here does not help:

<code>
protected void mapSearchResultToUser( SearchResult result, UserEntity user) throws NamingException {
    if (ldapConfigurator.getUserIdAttribute() != null && user != null) {
      user.setId(result.getAttributes().get(ldapConfigurator.getUserIdAttribute()).get().toString());
    }
    if (ldapConfigurator.getUserFirstNameAttribute() != null && user != null) {
      user.setFirstName(result.getAttributes().get(ldapConfigurator.getUserFirstNameAttribute()).get().toString());
    }
    if (ldapConfigurator.getUserLastNameAttribute() != null && user != null) {
      user.setLastName(result.getAttributes().get(ldapConfigurator.getUserLastNameAttribute()).get().toString());
    }
    if (ldapConfigurator.getUserEmailAttribute() != null && user != null) {
      user.setEmail(result.getAttributes().get(ldapConfigurator.getUserEmailAttribute()).get().toString());
    }
}
</code>

I still get the error from above with <code>Caused by: java.lang.NullPointerException
at org.activiti.ldap.LDAPUserManager.mapSearchResultToUser(LDAPUserManager.java:165)</code>

No idea why. Can anyone help? It would be great if the User Form Type would work with LDAP and it seems that we aren´t far from that because he finds the users in LDAP correctly! The only thing is this exception.

b_schnarr

The Problem seems to occur in the mapSearchResultToUser method in LDAPUserManager.java. The Steps
<code>user.setFirstName(result.getAttributes().get(ldapConfigurator.getUserFirstNameAttribute()).get().toString());</code> and
<code>user.setLastName(result.getAttributes().get(ldapConfigurator.getUserLastNameAttribute()).get().toString());</code>

are causing a Nullpointer-Exception. But I have no idea why… Could this problem occur when only the first one or two letters are typed in and then, the query tries to search for the user but does not find a user object?

Maybe, the line <code>if (ldapConfigurator.getUserIdAttribute() != null) {</code> must be extended to
<code>if (ldapConfigurator.getUserIdAttribute() != null && user!= null) {</code>

What do you think?

tombo

If we can determine why search fails with two letters but succeeds with four, maybe this will lead to solution. Where is boundary, three or four letters?
It's not a solution but what happens if search trigger condition is changed to >2 instead >=2?

b_schnarr

I tried it with <code> if (searchText.length() >= 3) {</code> and <code> if (searchText.length() >= 4) {</code>
If the trigger condition is set to >= 4, the error occurs not so often, but it still occurs….That makes sense because with 4 letters, the query has a better chance to find a user. The Question is why this problem does not happen with local users and how we could avoid them.

Just a thought: Lets say the trigger condition is set to 4. Nothing happens until the 4th letter is typed in. So far so good. Now, there are 2 possibilities. If there are users in the LDAP with names containing these letters, all is good. Otherwise, the error happens.

What is very strange: We have an LDAP User "Klaus Kerberos". With the first 4 letters (kerb), the query finds nothing. With 5letters (kerber), the query finds the user. What sense have the %-signs?

Thanks for your contribution

tombo

% sign is used as wildcard. For LDAP query we should replace this with *.

b_schnarr

Indeed, <code> List<User> results = ProcessEngines.getDefaultProcessEngine()
              .getIdentityService()
              .createUserQuery()
              .userFullNameLike("*" + searchText + "*")
              .list();</code>

works well with LDAP, but this error is still there. I have users without a forename or surename. Then, this errors occures. But there are several other users with a forename and a surename and this error occurs as well. I checked user and result for null, maybe this here is null?? <code> ldapConfigurator.getUserFirstNameAttribute()).get().toString()</code>

tombo

Could you try with <code>if (searchText.length() >3 )</code> and check behaviour on Klaus Kerberos user?

b_schnarr

I searched for Klaus Kerberos it with <code>if (searchText.length() >= 4) {</code> and got the error. When I use >= 3 or >=2, I get this error, too.

tombo

I was curious for condition > and not >=

b_schnarr

Same result with <code>if (searchText.length() > 3) {</code> even though Klaus Kerberos exists and he has forename and surename…
What I can say for sure: This error occurs when a user has no sur- or forename. But I do not know where to catch this…
I also tried with <code>       List<User> results = ProcessEngines.getDefaultProcessEngine()
              .getIdentityService()
              .createUserQuery()
              .userFullNameLike(searchText)
              .memberOfGroup("activiti_users")
              .list();</code>

only to list users which are in the group "activiti_users". But that query does not work. All Users where shown

tombo

For every attribute present in the configuration
<code>
<!– Attribute config –>
                <property name="userIdAttribute" value="cn" />
                <property name="userFirstNameAttribute" value="givenName" />
                <property name="userLastNameAttribute" value="sn" />
</code>
there must be attribute value present in the LDAP, otherwise error will be thrown.
When search for Klaus Kerberos is being performed and user found but anyway error occurs, is any other user displayed in list? If this user doesn’t have any of requested attributes populated, then this will explain that Klaus Kerberos user is found but error thrown anyway.

b_schnarr

Klaus Kerberos has cn = Klaus Kerberos, sn = Kerberos and givenName = Klaus. In the whole LDAP, there are just 2 users beginning with Ker: Kerberos and Kermit (both have fore- and surename). I use the rule > 3. When I type in "Kerm", the User Kermit is correctly found without error. When I type In "Kerb", the user Klaus Kerberos is not found and the error is thrown. When I add 1 letter (Kerbe), user Klaus Kerberos is found correctly. When I type in Klaus, the user is found correctly as well.

This is very strange. Is there a way to catch those exceptions? Because everything seems to be right with the user Klaus Kerberos. With the original rule >=2, this error occurs as soon as the first 2 letters are typed in. Maybe because then, more users are listed in the search box and in our LDAP, there are indeed users without fore- and lastname. With more letters, the search is more selective. Ok, accepted. But with user Klaus Kerberos, everything is fine.

Can you reproduce those errors? If we could catch this, we would be on the save side. At lease for a productive environment, the error should not be thrown. In addition, I do not understand the null pointer, because everything is checked for null…

Thanks your your answers

tombo

I'll try to confirm your findings but it will have to wait for next week, as I'm hard pressed with my job.
I'm interested to get this working.
For now, it looks like user search (which is done against cn attribute) works well only with beginning 4 letters of user name (Kerm, Klaus,..). Maybe you could look in to the userFullNameLike method from UserQueryImpl.java which compares user name values.

b_schnarr

Thank you. The thing is that I do not understand why it runs in a null pointer. Because the attributes were only set when <code>ldapConfigurator.getUserFirstNameAttribute() != null</code>
I also added <code> && user != null && result != null</code>

Without success.

tombo

Disclaimer! I'm an old fart and been dealing with programming for less than two years. My comments might be wrong due to lack of knowledge. (would be nice signature)

Now, <code>ldapConfigurator.getUserFirstNameAttribute() != null …</code> sets attribute value if „userFirstNameAttribute“ exists in the activiti-standalone-context.xml, and it does exist.
Edit:
Condition result != null is ~~never met~~ is not necessary as there is always something in the resulting LDAP query.
You should first get attribute value and check whether is null and if not then set attribute value in the LDAPUserManager.java (your post #10).

b_schnarr

Ok, but where should I check the attribute value?

tombo

Could you test this code?
<code>
    if (ldapConfigurator.getUserFirstNameAttribute() != null) {
        String attributevalue = result.getAttributes().get(ldapConfigurator.getUserIdAttribute()).get().toString();
        if(attributevalue==null || attributevalue.trim().length()==0 || attributevalue.equals("null")) {
     user.setFirstName("DummyValue");
        } else {
      user.setFirstName(attributevalue);
    }
    }
</code>
Apply the same for LastNameAttribute

b_schnarr

Tried it and I get <code>Caused by: java.lang.NullPointerException
at org.activiti.ldap.LDAPUserManager.mapSearchResultToUser(LDAPUserManager.java:170)</code>

In my case, line 170 is this here:

<code>String attributevalue2 = result.getAttributes().get(ldapConfigurator.getUserLastNameAttribute()).get().toString(); </code>

tombo

Ah, Catch- 22. We should know that string is null before we get it's value. On the other side, it's clear that attribute value is coming as null from the LDAP.
So, every LDAP user must have all attributes populated. I don't see other way to handle this. Question remains, why is search working with +1 letter (from condition number) if search string phrase is equal to second part of user name (for Klaus Kerberos works with Klau but not with kerb).

b_schnarr

Exactly. Maybe, the activiti developers have another idea? @tombo, thanks for you contribution and your fast answeres!

tombo

Last shot. We could try handle NPE event? (I hope that code is right)
<code>
    if (ldapConfigurator.getUserLastNameAttribute() != null) {
            try {
            user.setLastName(result.getAttributes().get(ldapConfigurator.getUserLastNameAttribute()).get().toString());
            } catch (NullPointerException npe) {
                user.setLastName("DummyValue");
            }
        }
</code>

b_schnarr

So often, the easiest answer is the right! It works! With this here
<code>
protected void mapSearchResultToUser( SearchResult result, UserEntity user) throws NamingException {
    if (ldapConfigurator.getUserIdAttribute() != null) {
      user.setId(result.getAttributes().get(ldapConfigurator.getUserIdAttribute()).get().toString());
    }
    if (ldapConfigurator.getUserFirstNameAttribute() != null) {
     try{
      user.setFirstName(result.getAttributes().get(ldapConfigurator.getUserFirstNameAttribute()).get().toString());
     }catch(NullPointerException e){
      user.setFirstName("");
     }
    }
    if (ldapConfigurator.getUserLastNameAttribute() != null) {
     try{
      user.setLastName(result.getAttributes().get(ldapConfigurator.getUserLastNameAttribute()).get().toString());
     }catch(NullPointerException e){
      user.setLastName("");
     }
    }
    if (ldapConfigurator.getUserEmailAttribute() != null) {
      user.setEmail(result.getAttributes().get(ldapConfigurator.getUserEmailAttribute()).get().toString());
    }
}
</code>

Everything works fine. And the mystery with Klaus Kerberos is solved, too. There was a third user beginning with ker, the user "waskerb". This user has no lastname. Therefore, when i typed in "kerb", there were 2 users matching: Klaus Kerberos and "waskerb". Because waskerb has no name, the exception was thrown. Now, both Users are displayed correctly in the User Form Type!

I know that you sould not catch Runtime-Exceptions, but it can always happen that a user has not all properties in LDAP. Therefore, activiti developers, could you add this try-catch Block in the official distro? That would help a lot of people and then, the user form type can be used with LDAP.

Very cool!!

Thanks a lot @tombo for the great ideas.

tombo

Excellent. Thank you for doing the actual job.
Those several small changes, along with extra password check, bring back important functionality for the enterprise environment.
My own conclusion, based on the finished project, is that activiti-explorer can be used in production environment. I understand developers point that it's just technology demo (because there are other priorities), but it has to many functionality built in to be easily replaced with your own solution.
Regards,
Boris

b_schnarr

I am exactly of the same opinion. Therefore, it would be great if those several lines of code could be integrated in the official distro.

jbarrez

Thanks for diving into that guys!

Added fix: https://github.com/Activiti/Activiti/commit/7e6353942597c114f480ecf8c5578b44511c76f2

kgiannakakis

LDAP integration with activiti-explorer is a a hard requirement for me as well. I have two comments to make regarding the provided solution.

1) Why not null checking for email as well. In my opinion a user with a missing mail attribute is much more likely than a user with a missing first or last name:

<java>
if (ldapConfigurator.getUserEmailAttribute() != null) {
    try {
        user.setEmail(result.getAttributes().get(ldapConfigurator.getUserEmailAttribute()).get().toString());
    }catch(NullPointerException e){
        user.setEmail("");
    }
}
</java>

2) The '%' character in search like query is a problem for LDAP searching. It is better to handle this in ldap module than in the activiti-explorer (org.activiti.explorer.ui.custom.SelectUsersPopupWindow.searchPeople). Something like the code below in LDAPUserManager.findUserByQueryCriteria will do:

<java>
} else if (query.getFullNameLike() != null){

final String fullNameLike = query.getFullNameLike().replaceAll("%", "");

LDAPTemplate ldapTemplate = new LDAPTemplate(ldapConfigurator);
return ldapTemplate.execute(new LDAPCallBack<List<User>>() {

    public List<User> executeInContext(InitialDirContext initialDirContext) {
      List<User> result = new ArrayList<User>();
      try {
        String searchExpression = ldapConfigurator.getLdapQueryBuilder().buildQueryByFullNameLike(ldapConfigurator, fullNameLike);
</java>

jbarrez

kgiannakakis, thanks for the comments. Would it be possible to wrap those code changes in a pull request so we can see the actual changes and discuss it properly?

kgiannakakis

Thanks for the response. I have created the pull request:

https://github.com/Activiti/Activiti/pull/581

jbarrez

Thanks! Will discuss further on the Pull Requests there.