Description of problem:

The jbpmHumanTasksWithUser dataset (which is used to display task lists in the business-central UI) uses the following query:

select  t.activationTime, t.actualOwner, t.createdBy, t.createdOn, t.deploymentId, t.description, t.dueDate,t.name, t.parentId, t.priority, t.processId, t.processInstanceId, t.processSessionId, t.status, t.taskId, t.workItemId, oe.id oeid 
from AuditTaskImpl t, PeopleAssignments_PotOwners po, OrganizationalEntity oe 
where t.id = po.task_id and po.entity_id = oe.id

It links the primary key of the AuditTaskImpl table to the taskId in PeopleAssignments_PotOwners.

So this query assumes that the primary key of AuditTaskImpl is always the same as the taskId. 
With MySQL (I didn't test with other DB's), the primary key of AuditTaskImpl is generated with AUTO_INCREMENT

In my tests with bpmsuite-6.2.0.ER5 with MySQLDB it happened a couple of times that the primary key of rows in AuditTaskImpl was no longer the same as the taskId of the same row. As a result the jbpmHumanTasksWithUser dataset returned erroneous results, breaking the task list UI functionality in business-central. I do not recall the precise conditions in which this mismatch happened, so I cannot reproduce easily.

Possible solution: link AuditTask.taskId to PeopleAssignments_PotOwners.task_id

So the query becomes:

select  t.activationTime, t.actualOwner, t.createdBy, t.createdOn, t.deploymentId, t.description, t.dueDate,t.name, t.parentId, t.priority, t.processId, t.processInstanceId, t.processSessionId, t.status, t.taskId, t.workItemId, oe.id oeid 
from AuditTaskImpl t, PeopleAssignments_PotOwners po, OrganizationalEntity oe 
where t.taskId = po.task_id and po.entity_id = oe.id 

Version-Release number of selected component (if applicable):
bpmsuite-6.2.0.ER5/


How reproducible:
Difficult to reproduce

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: