Inconsistent Handling of IdentityLinks for tasks about flowable-engine

[motorina0]

This is a problem I have encounter while trying to implement #123
The current approach might be desired way of handling the Identity Links (for performance problems).
I need confirmation/infirmation on this.

There is a comment in the GetIdentityLinksForTaskCmd class regarding the issue:

    // assignee is not part of identity links in the db.
    // so if there is one, we add it here.
    // @Tom: we discussed this long on skype and you agreed ;-)
    // an assignee *is* an identityLink, and so must it be reflected in the
    // API
    //
    // Note: we cant move this code to the TaskEntity (which would be
    // cleaner),
    // since the task.delete cascaded to all associated identityLinks
    // and of course this leads to exception while trying to delete a
    // non-existing identityLink

[motorina0]

I did implemented the fix. Will make a pull request with the changes.
The project owners will decide if they will merge them or not.

[tijsrademakers]

Hi,

For assignee and owner the values are stored with the task entity. The participant type identity link that is created is additional and has another meaning. Every assignee of a task will be added as participant for the process instance by default.

So I think the IdentityLinkEntityManager.findIdentityLinksByTaskId method should be used and the participant type identity links created for assignee and owner belongs to the process instance execution and not to the task, so they can be ignore for the task identity links.

[motorina0]

Hi Tijs,

Thanks for the prompt answer. After "fixing" the issue, I have better understood how the identity links are handled :)

One topic that I consider open is the HistoricIdentityLinksForTask
In the current (implicit) approach the owner and assignee updates are not available in history.
In the explicit approach (create identity links for owner and assignee) the full history can be queried.

See new unit test:

https://github.com/motorina0/flowable-engine/blob/ccf2c6928a63a4406d3d1c085617965ebc61cf94/modules/flowable-engine/src/test/java/org/flowable/engine/test/history/HistoricTaskInstanceTest.java#L597

All changes are here:

master...motorina0:issue_133#diff-c581222409bed86ebef60c7bd5c72a81

[tijsrademakers]

Hi,

I think it would be nice to have the owner and assignee updates available in the history. But in the changes I see on your branch you also changed the participant involvement into an explicit assignee and owner identity link for the runtime identity link table. The assignee and owner links are implicit because they are already stored in the act_ru_task table. I don't think this should be changed now, but making the owner and assignee updates available in the history might still be a good thing to do. What do you think?

[motorina0]

I think it is a god idea that has both benefits:

• it keeps an explicit history of the task assignee and owner
• it allows assignee and owner links to be implicit (more performant) for run-time tables

I will implement it this way.

[motorina0]

Implemented. Added unit tests. Created pull request.

[motorina0]

Pull Request merged.