feat(engine)Delegation on user level

[salajlan]

Related to CAM-4760

[buildhive]

camunda BPM » camunda-bpm-platform #1745 UNSTABLE
Looks like there's a problem with this pull request
(what's this?)

[ThorbenLindhauer]

Hi @Suliman-Ajlan,

We're not yet sure whether we would like to have such a feature in the core engine at this time and we'll discuss this internally and then get back to you.

Note that it is possible to implement this delegation pattern with TaskListeners as well. So the additional functionality your pull request adds on top of that is that the delegation information is managed internally in the user table. We'll have to discuss if we want to manage these things internally. If this is the case, we can discuss your implementation in a second step.

Cheers,
Thorben

[ThorbenLindhauer]

Hi @salajlan,

Sorry for the late follow-up on this from my side. We are still interested in having this feature. However, it would be better to implement it in a more generalized way. A generalized implementation should allow for relationships other than just delegation to a single user and provide an API for arbitrary user/group relationships.

Since this decision very likely influences the database schema that we cannot easily change in future releases, we should try to build the generalized version in the first step already.

Are you interested in providing this? Then I could give you some hints how this could look like and pointers to code that would have to be adapted. Shouldn't be too complicated.

Cheers,
Thorben

[salajlan]

Hello @ThorbenLindhauer,
Good to hear that, And I'm really interested to help and to provide this feature.
Your hints will be helpful.

Thanks,

[ThorbenLindhauer]

Hi @salajlan,

I imagine something like the following:

• Add TaskService API methods to define relationships between user<->user, group<->group, user<->group. A relationship has a type that is identified by a name. So an API could look like TaskService#saveUserUserRelationShip(String userId, String relatedUserId, String type).
• Add a TaskService API method to query for relationships, e.g. TaskService#getRelation(String userId, String type). This would return a list of relationship objects that identify the type of relationship, the type of related entity (user or group) and the id of that entity.
• The idea behind this API is that it allows users to freely implement task listeners and query any kind of relationship to assign/offer tasks to the right persons/groups.
• Use these methods to implement the delegation relationship when a task is assigned. That could either be directly in the TaskDecorator or in a TaskListener. Having it in a TaskListener could be nice since users can then easily toggle this behavior in the process engine configuration.
• To implement relationships querying, the interface ReadOnlyIdentityProvider could be extended. The default database-backed implementation would make a SQL query while an LDAP-backed implementation would look up the relationships in a different way. We need not implement LDAP, but there should be a way to do it.
• To implement relationship creation, the interface WritableIdentityProvider could be extended in a similar way.
• Perhaps there has to a distinction between bi-directional and uni-directional relationships. For example, delegation would be uni-directional meaning that user A is allowed to handle user B's tasks but not the other way round. However, there may be relationship types that work both ways. We could also ignore this in the first increment of the feature.
• In the database schema, find a way to persist these relationships. One way could be an entirely new table. Another could be extending the table ACT_ID_MEMBERSHIP, since group membership is just one form of relation between users and groups. If we extend ACT_ID_MEMBERSHIP, we have to provide a migration SQL script. Table layout is a particular interesting topic here. There should be proper indexes for efficient lookup.

This is a proposal and not meant as "please do exactly this". Feel free to discuss this and propose improvements.

Cheers,
Thorben

[ThorbenLindhauer]

Hello @salajlan,

I hope I did not overwhelm you with this. Did you already have the time to think about the proposal and decide whether you would like to implement something in that direction?

Cheers,
Thorben

[salajlan]

Hello @ThorbenLindhauer,
I was reviewing your proposal with the codes and seems interesting, but I'm new on this so it may take some time.
I want to ask you one thing, we speak here on User Level why you use TaskService rather than IdentityService for relationship defining and querying?

Thanks,

[ThorbenLindhauer]

Hi @salajlan,

I agree, that should be part of the IdentityService rather than TaskService. If you have any further implementation-related questions, let me know.

In order to proceed, I will close this pull request since we decided to not merge it in its current state. When you had the time to look into the proposal and implement it (or larger parts of it), you can update the pull request and reopen it to receive feedback. Closing helps us keep track of the pull requests that need action on our side.

Cheers,
Thorben