candidateStarterGroups and custom user & group tables

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.

edwinvds

Hi,

We have just migrated from the built in user & group tables ( act_id_user & act_id_group ) to our own set of tables. After the migration I noticed that the candidateStarterGroup functionality no longer works, which worked fine before the migration. This functionality allows you to tag the BPMN process with the activiti attribute  activiti:candidateStarterGroups , as explained here http://activiti.org/userguide/#security

Using a BPMN process element:

   

<process activiti:candidateStarterGroups="mygroup" id="myprocess" name="My Process">‍

And given a user named "user1", member of "mygroup" , the following code would return the expected process definition, but no longer does:

    //org.activiti.engine.RepositoryService
    repositoryService 
        .createProcessDefinitionQuery()
        .startableByUser("user1")
        .list();‍‍‍‍‍

I've narrowed it down to the query defined in ProcessDefinition.xml , which is joining the wrong user and group tables :

      <if test="authorizationUserId != null">
        AND (exists (select ID_  from ${prefix} ACT_RU_IDENTITYLINK  IDN where IDN.PROC_DEF_ID_ = RES.ID_ and IDN.USER_ID_ = #{authorizationUserId})
             OR exists (select IDN.ID_  from ${prefix} ACT_RU_IDENTITYLINK  IDN,  ${prefix} ACT_ID_MEMBERSHIP MBMR where IDN.PROC_DEF_ID_ = RES.ID_ and MBMR.USER_ID_ =  #{authorizationUserId} and IDN.GROUP_ID_ = MBMR.GROUP_ID_)
             )
      </if>
‍‍‍‍‍‍

     
So my question is twofold:

• is this a bug or a feature ?
• what is the best way to override the built in query, without patching Activiti ?

Thanks,
Edwin

frederikherema1

Hi edwin. The "starter" functionality was added recently to activiti and it seems it's not completely identity-implementation agnostic, as it should be. So this is a *feature*

When querying for tasks 'assigned to user', for example , this is done using 2 queries: one for fetching user's groups and a second query fetching the actual task, using the returned group-ID's. So this approach should be applied to the candidateStarterGroup I guess, in order to fix the issue you're facing. I'm afraid you're currently obligated to patch the activiti codebase/jar you're using right now to overcome/replace the join with membership-table.

Issue created in JIRA: https://jira.codehaus.org/browse/ACT-1416