Container type: AQ_File_Upload

With the container AQ_File_Upload it is possible to upload and store multiple files.

Note that all files that are selected will be handled as a bundle. That means that if at least one file can not be uploaded (e.g. because it has not the correct extension or because it is larger than specified) the entire set of files will not be uploaded.

Parameters

Event

This container can contain an event: FileUploaded. With this event it is possible to perform a flow action after the upload of each file (only applicable when the set of files is ok). Note that for multiple files a repeat condition has to be stated which should be put on a sub-flow.

The Unauthorized exit is triggered when updating a file for which the user does not have one of the needed roles.

Validation

Files that are uploaded through the file upload container are validated against the following checks:

• FileSize is validated against the MaxFileSize, which can be set as a parameter of the container.
• File extension is validated against the allowed extensions, which can be set as a parameter of the container.
• File names can only consist of the following allowed specific set of characters and digits:
  • a-z lowercase and uppercase and with or without diacritics 
  • digits zero until nine
  • special characters _!@#$€%^&,.-+`~"-[]() and space 
• File ContentType is validated against the allowed extensions.
• The amount of files is validated against the MaxFileAmount, which can be set as a parameter to the container.

Maximum file size

The maximum file size that can be uploaded is determined by a number of factors, of which not every factor is in control of Blueriq. 

1. MaxFileSize on the AQ_File_Upload container
2. the blueriq.fileupload.maxuploadsize property (see Miscellaneous Properties)
3. the network infrastructure
4. the (application) server settings

Only the first two can be controlled by Blueriq.

The MaxFileSize on a container is enforced by the frontend (e.g. the Material theme) and the Blueriq Runtime. If a custom frontend is used, it is strongly advised to validate the file size for uploads.

The blueriq.fileupload.maxuploadsize property is enforced by the Runtime backend. If the size of a request is higher than this property, the request is aborted. This is a security feature, as it is otherwise possible to attack a server with very large requests. We strongly advise to set this property. It is important to note that contrary to the MaxFileSize on a container, which is per file, this property is per request, meaning that when you upload multiple files, the total size is counted.

Note that an aborted file upload request means that the progress bar in the UI will hang. Therefore, we recommend to set the blueriq.fileupload.maxuploadsize property to a sufficiently high value, so that this limit is not easily reached with normal use.

Regardless of what you set in Blueriq, there can still be network and application server limits that are imposed on uploads. When an upload fails, this should be taken into account when investigating the cause of the problem. As a general rule, Blueriq should be more restrictive than the network/server settings, so that if an upload is too large, Blueriq can handle it. For example:

• MaxFileSize: 10485760 (= 10 MB)

• blueriq.fileupload.maxuploadsize=26214400 (= 25 MB)

• network/server restrictions 50 MB

Note that in this scenario if you upload 3 files in one go which are each a little less than 10 MB, your upload will still get aborted because it exceeds the blueriq.fileupload.maxuploadsize parameter.

Validations

The AQ_File_Upload container contains the Required parameter. If the parameter evaluates to TRUE the container will validate if a file has been successfully uploaded to that container. When no files have been successfully uploaded the container will display a validation error.

Note that with the RelationToFileInstance  parameter, you can can add validations to the relation attribute. This is a more powerful mechanism than the Required  parameter, as it allows to express requiredness, but also more detailed validations such as "at least one document of type X needs to be uploaded", or "if a document of type Y is uploaded than you also need to upload a document of type Z", etc. etc. Another benefit is that you can customize the validation message. So in general the RelationToFileInstance  parameter in combination with validations is preferred over the Required  parameter.

Validations added to the validation rule must be blocking, as the flowing mechanism is actively blocked when a validation rule is not met. This means that when you define non-blocking validation rules (e.g. warnings), they are ignored. As these non-blocking validation rules are more of a hint to the user, you should convey this information in another way in this use case.

When you have multiple upload containers on a page and validation is triggered (by submitting the page for example), only validations (if any) for the top upload container will be displayed. This is because flowing (and validating) stops right after a validation rule is not met. This means in practice that if you have multiple upload containers which each have validations on them, the top one will be displayed, then if you "fix" that, the next one will be displayed etc.

Messages

Labels, descriptions, validations (such as "File is too large"), and status messages can be changed in the messages.properties files. An example can be found here: Reference Guide: Properties.

Note on persistence

Related articles

• Page:
  How to handle multiple files