Add file upload and download capability

[CharlesIrvineKC]

In general, I need to be able to both upload and download files from the Camunda database. This is currently supported by Camunda's embbedded forms capability. See

https://docs.camunda.org/manual/latest/reference/forms/embedded-forms/controls/files/

To implement this, I would imagine that you would add a field type of file.

If the field is not marked readonly, the user would be able to specify a file to upload. If a file has already been uploaded with the provided field name, then the user would be able to upload a new file.

If the field is marked readonly, then the user would only be able to download the previously uploaded file.

In my opinion, this is a critical feature - critical for me anyway. I've used this embedded forms capability often.

Note: the last I checked, a readonly property was not yet supported, but I was told by another Camunda forum user, that the feature had been implemented and would be included in the next Camunda release. Do you know if this is true? I think that readonly fields are an even more critical feature.

[nikku]

We'll likely not ship this as a capability out-of-the box.

Someday maybe though this library will be extensible to allow data uploads (and downloads) as you describe.

[CharlesIrvineKC]

I suspected that this would be the case, but why not? Thanks

[dfulgham]

@ChuckIrvine Is this what you had in mind?

I have it working for Base64 encoding for the uploaded file, I was going to expand it to allow limiting file types as well.

[CharlesIrvineKC]

@dfulgham That looks awesome! It seems that you guys have decided to do this. If so, I think it's a great addition to the tool. Thanks!

[dfulgham]

@dfulgham That looks awesome! It seems that you guys have decided to do this. If so, I think it's a great addition to the tool. Thanks!

I'm not "you guys" :) but yes I will be creating a pull request to see if they want to add it.

[CharlesIrvineKC]

@dfulgham Sorry, David. When I said "you guys", I guessed that the Camunda team was coding this feature. I guess now that isn't true. Too much guessing maybe. I hope this feature is pulled in. I think the file type field is very valuable. Thanks, again.

[christian-konrad]

We will not pull in this feature yet as a default due to certain things to be considered beforehand. There would be more work on this, which we may consider in the future. It could cause problems in process execution engines, especially in the Camunda engines:

• We do not want to store documents encoded as Base64 in process instances in the long term
• Base64 is the opposite of compression. Too large especially with a lot of process instances. The document payload should be stored elsewhere and only a reference should be returned in the form input json
• It bypasses any access control in the target system (e.g. DMS): original is still always available in the process instance
• Executable malicious files can be stored without validation, which will become problematic later on
• All logics of a DMS or Object Storage are bypassed.

What would be useful here: A kind of “connector” API to the target storage, so that when submitting the form, the document is automatically uploaded and a reference to the document is created and the base64 replaced by that reference - But this causes a new question: What about processes that should react to newly uploaded documents in the target storage?

Hope you understand this issues, there is something to do to enable this great idea :)

[dfulgham]

I believe it should be up to the client application that is using the form.js library to determine how to use the javascript object submitted from the form, ie. whether to store the file property into a storage database rather than keep it as part of the JSON that might eventually go to a server or Camunda for example.

I think that the form.js library should remain client/server solution agnostic as it is simply a javascript form library.

For example, what if I wanted to only process the file with an OCR library on the client before then sending the data to a database? Having the business logic built into the form library would be too restrictive.

If needed I could have an option on the file component that would allow the object to be stored as Base64 encoding or a Blob.

For further debate, this is how Camunda handles File-Type Variables, A Form can submit them into process variables as Blobs. ( https://docs.camunda.org/manual/7.14/user-guide/process-engine/variables/#file-values ).

On Tue, 15 Mar 2022 at 07:30, Christian Konrad @.***> wrote:

We will not pull in this feature yet as a default due to certain things to be considered beforehand. There would be more work on this, which we may consider in the future. It could cause problems in process execution engines, especially in the Camunda engines:

• We do not want to store documents encoded as Base64 in process instances in the long term
• Base64 is the opposite of compression. Too large especially with a lot of process instances. The document payload should be stored elsewhere and only a reference should be returned in the form input json
• It bypasses any access control in the target system (e.g. DMS): original is still always available in the process instance
• Executable malicious files can be stored without validation, which will become problematic later on
• All logics of a DMS or Object Storage are bypassed.

What would be useful here: A kind of “connector” API to the target storage, so that when submitting the form, the document is automatically uploaded and a reference to the document is created and the base64 replaced by that reference

• But this causes a new question: What about processes that should react to newly uploaded documents in the target storage?

Hope you understand this issues :)

— Reply to this email directly, view it on GitHub https://github.com/bpmn-io/form-js/issues/222#issuecomment-1068054359, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALRFLH6DZ2TJYY22JAW7SLVACNIBANCNFSM5NYFUL6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[christian-konrad]

I understand your argument; from a client application perspective, this totally makes sense. It is true that we want form.js to simply be a client-side form library. Unfortunately (and somehow contradictory), form.js in its current state is not sufficiently decoupled from process engines and processing use cases, so we need time to handle it properly before merging it in the default codebase.

We are thinking about extensibility mechanisms, providing a simple API to add form fields of your choice, which makes it easier to have those features without caring about dependencies on Camunda engines, and letting the embedding environments decide which form fields are exposed.

Fyi: To progress on this, I opened an issue: https://github.com/bpmn-io/form-js/issues/237

[dfulgham]

Fyi: To progress on this, I opened an issue: #237

I'm on it.