Error when you reuse the form field of the attachment (upload) type

Flowable Engine
1

When you reuse the form field of the attachment type the error is displayed:

09: 33: 23,471 [http-apr-8080-exec-9] ERROR org.flowable.engine.common.impl.interceptor.AbstractCommandContext - Error while closing command context
Java.lang.ClassCastException: java.util.ArrayList can not be cast to java.lang.String

2

Ok thanks. What is the behaviour you are looking for? Do you want to be able to add additional attachments in the second form? The use case that is implemented currently is that you can use an attachment field and then an expression field to display the uploaded attachment.

Best regards,

Tijs

3

Hi,

I have also encountered this problem.

My usecase is that a ServiceTask creates a Word document and we attach it to the process (using the content Engine and saving the content ID as a process variable).
Then at a later step the document is made available to the end user using a ‘readOnly’ upload field. This is essentially a download field.
I can also see another usecase that in a UserTask you upload a file and later is the process you want to offer the user to re-upload/upload a new version. By re-using the upload field with the same ID this allows the user to upload again or not. If a new ID was used then we would need a servicetask (or similar) to handle combining the old and new fields.

@tijs I have actually made a fix in the flowable-task app which seems to solve this issue.
The problem seems to be that the upload field expects a comma separated list of content IDs when saving, but when reading the form value a JSON list of content objects is returned from the API. If no new file is uploaded then it is this list that is returned when completing the form and causes the error above.

I have made a patch here https://github.com/paulstapleton/flowable-engine/commit/0f564b5944c808b9f69b676daff95d1dc1d1474d if you are interested in accepting this into Flowable I can create a pull-request/Github issue. Please let me know how you would like to proceed.

Regards,
Paul

4

Hi Paul,

Thanks. For this use case an expression field could also be used I think. For the second use case not of course. The patch does look ok so would be good to check. Does it also deal with deleting a previously added attachment from the database, when you would add a new attachment in a second form?

Best regards,

Tijs

5

Tijs,

My case is for example in a request the user attaches a document which in the following activity this document should be viewed to be analyzed for approval.
When you try to reuse the read-only attachment form field, you can view the attachments, but when you try to complete the task the error is displayed.
I tried using the Expression field as suggested, but the attachment is not shown in the task. The expression field displays only a number such as 2ca2ed53-325a-11e7-94e0-005056ad6f76.
I’ve also tested if it does not set to read-only and add another file actually the error does not happen.

6

Hi,

@robsoncardoso.ti The problem with reusing the field in read-only mode is fixed by my patch.
But I also failed to get the expression field to work.
@tijs do you have an example of how this should work?

@tijs I also tested removing a previously added attachment and this does not remove it from the file system and I suspect not the database either (I havent actually confirmed this). When removing an attachment from the upload field no requests are made to the server.
However, I note that this is a problem already today if a user uploads a file, realises it was the wrong file and uploads a different one). The original attachment is not removed.

Another thing I noticed is that the attachment is saved in the ‘uncategorized’ folder on the file system. Is this intended? should it not be related to the task or process instance?

Anyway I have added my fix as a pull request - https://github.com/flowable/flowable-engine/pull/376

Regard,
Paul

7

Pstapletron,

Thanks for the correction.
I hope the PR is accepted and will be available soon.
I do not believe the expression field is adequate to show the attached documents. The read-only property for the attached field would be the best way to display the attached documents to be viewed.

8

Thanks Paul, I’ve merged the PR.
I think the uncategorized folder is correct for the current implementation. Only content added to a process instance or a task directly are added to the process-instance or task folder.

Best regards,

Tijs

9

Resurrecting this post: I can’t seem to reproduce @pstapleton’s approach of a ‘read only upload field’.

I have an HTTP task that sends an uploaded file off to an external REST endpoint for processing. I’d like that endpoint to also return another file for review.

I can POST the new file as a content-item and pass back the content-id as a process variable. If I then set a read-only upload field to this content-id (i.e. a download field) it comes up blank. Further, I can’t download the uploaded file, only clear the upload field and add a new file.

I thought about POST-ing the file as a task attachment, but alas the REST endpoint doesn’t know the id of the review task to attach it to, only the task-id of the HTTP task it the request originated from.

Any help would be hugely appreciated.
Andrew

10

The plot thickens. The ability to download a file from an upload field appears once the process is complete. If I navigate back to the task the upload field is fixed and a download icon appears.

Is there some way to enable this while the process is still running?