cancel
Showing results for 
Search instead for 
Did you mean: 

Information in workflow records cannot be trusted.

lyles
Champ in-the-making
Champ in-the-making
It looks like there are a few problems with Alfresco workflows that result in missing or incorrect information recorded in the details of a workflow. The problems occur in Alfresco 4.0.d. and can all be easily reproduced with the out-of-box review and approve workflows. I haven’t tested in any other version.

1) A pooled task can be completed without first claiming it and there is no record of who completed the task. The owner property of the task is unset and displays as “(none)” in the task and workflow details pages in Share.

Relying on the user to claim the task but still allowing them to complete it without claiming it does not make any sense. The task owner should be set to the current user if they click on the accept or reject button and that results in a successful completion of the task, regardless of whether or not they have first claimed the task. There must be a way to set the task owner to the current user, but I haven’t been able to figure it out and every way that I’ve tried has failed. I also tried setting the taskOwner field to be mandatory, expecting that the user would not be able to complete the task without first claiming it, but that had no effect.

2) Any workflow task can be completed by the initiator of the workflow and the record will indicate that the assignee completed it. It may be a feature and not a bug that allows the initiator to complete all tasks themselves, but it should at least record that it was the initiator that completed the task instead of entering false information into the record.

3) When a task from a set of parallel tasks is completed and satisfies the completion condition for the set of tasks, the outcome and comments are copied to all of the remaining tasks in the set that have not yet been completed. The out-of-box parallel review and approve workflow demonstrates the problem.

I’ve researched the issues and #2 has a JIRA for v3.4: https://issues.alfresco.com/jira/browse/ALF-12507, but it won’t be fixed and the comment from the assignee indicates that having false information in the workflow record is not a concern!  I wasn’t able to find any JIRAs on the other two problems, but since they also have to do with false information in the workflow record, there is no point in reporting them.

I have a custom workflow that exhibits all three problems. By the time that the workflow reaches the top level manager, the workflow details may be a complete mess of incomplete and false information that cannot be trusted.

Any advice or help fixing these problems would be much appreciated.
4 REPLIES 4

mrogers
Star Contributor
Star Contributor
Please raise the other two issues otherwise they will not even be considered.  

Also a wont-fix does not mean it will never be fixed.   The issue is now with project management to consider.    I suggest you add some comments with your concern.      And my reading of the issue is that it is mainly dealing with who can work on the issue rather than who is in the workflow history.

lyles
Champ in-the-making
Champ in-the-making
I've added my comment to the related JIRA and raised two new ones:

https://issues.alfresco.com/jira/browse/ALF-13901
https://issues.alfresco.com/jira/browse/ALF-13902

Still looking for advice on how to modify the code myself.
The "Claim" button for pooled tasks assigns the task to the current user. That code and resulting behaviour needs to be duplicated for the accept and reject buttons. But I don't know where to look to find that code.

lyles
Champ in-the-making
Champ in-the-making
Could someone look at the two JIRAs that I submitted and explain what happened.

They were both quickly marked as "Fixed", as well as another related JIRA that hadn't seen any activity since February.
I'm new to the process of submitting bug reports for Alfresco and I don't understand what occurred to make them "Fixed".

mrogers
Star Contributor
Star Contributor
The code was fixed!  Isn't that clear?

Next step is for QA to validate the fix.

These fixes should be in the Enterprise 4.0.2 service pack.  
And the next community release.     The one I checked is already on HEAD as well so will be in the "nightly build".