Upload

Modern multi-file upload control with drag & drop, document-type awareness, live progress and attachment auto-linking. It replaces the bare FileImport input and is optimized for on-form uploads without switching to the attachment sidebar.

Feature highlights

  • Drag & drop or button-based selection with inline queue, per-file status chips and remove/retry actions.

  • Optional document type selector that reuses the global Document Type catalog and can be enforced before any file is accepted.

  • Built-in validation for file extensions, blacklists, max size and max item count, surfaced directly beneath the control.

  • Automatic linking to the current record via the Attachment API, so uploaded files show up on the attachment sidebar without extra scripting.

  • New OnUpload and OnUploaded events for last-second validation, automation and status handling.

Configuration surface (new properties)

All properties reside on the control definition (AppConfig JSON) and are exposed in the Config Editor under the "Upload" category. Only the new settings introduced with the control are listed below.

UploadDocumentTypeMode

Controls whether end users must choose a document type before uploading.

Value
UI behavior
When to use

Hidden (default)

No selector is shown. The control will use AttachementDocTypeId or the backend default when linking.

For apps with a single document type or where doc type is set in automation.

Optional

Shows a dropdown that is pre-populated from Attachment/GetDocumentTypes. Preselects AttachementDocTypeId when provided.

Let users override the document type on demand.

Required

Same as optional, but the dropzone stays disabled until a value is chosen. A badge indicates the requirement.

Compliance scenarios where every upload must have an explicit document type.

The selector is populated once and cached. If you switch languages, labels are returned directly from the Document Type repository.

UploadAllowedExtensions

  • Type: string (comma/semicolon/space separated list, dots optional).

  • Purpose: Defines a whitelist (e.g. .pdf,.png .jpg). When the list is not empty, only matching extensions pass.

  • Behavior: The list is normalized (lowercase, prefixed with .), rendered as an accept attribute and shown in the legend to inform users. Combine with UploadBlockedExtensions for finer control.

UploadBlockedExtensions

  • Type: string (same format as the whitelist).

  • Purpose: Defines extensions that should never be accepted (e.g. .exe; .bat).

  • Behavior: Evaluated after the whitelist. Even if the extension is part of the allowed list, it will still be rejected when explicitly blocked.

UploadMaxFileSizeMb

  • Type: integer (MB), default 0 (= unlimited).

  • Purpose: Rejects files larger than the specified size before the upload starts. The limit is also displayed to users.

  • Notes: The check runs on the client but you should still keep server-side size limits aligned.

UploadMaxFiles

  • Type: integer, default 0 (= unlimited).

  • Purpose: Caps how many files can be queued/uploaded in this control instance.

  • Behavior: Blocks additional files once the limit is reached and shows the ErrorMaxFiles message. When users drop more files than allowed, the control keeps the first MaxFiles entries and warns about the truncation.

Runtime behavior

  1. (Optional) Users select a document type; the dropzone is disabled until a selection exists when the mode is Required.

  2. Files are dragged/dropped or chosen via the hidden input button.

  3. Client-side validation kicks in: max count, size, whitelist/blacklist checks. Errors are displayed inline above the queue.

  4. For every accepted file the control:

    • Adds it to the queue with a status badge (Queued → Uploading → Done/Error).

    • Sends an OnUpload event. Returning false cancels the upload for that file only.

    • Uploads the binary via Attachment/Upload, optionally applies the file-name template (AttachementFileName) and sets the document type through Attachment/SetDocumentTypeId.

    • Links the attachment to brixxApi.attachmentAppName/brixxApi.attachmentRecordId (when available) via Attachment/LinkAndDocumentType.

    • Fires OnUploaded with the resulting metadata.

If the form has not saved a record yet, the file will upload but cannot be linked. Handle this case in OnUploaded or block uploads via OnUpload.

Events

  • OnUpload: Triggered per file before the binary is sent. Use it for client-side validation or to cancel uploads dynamically.

  • OnUploaded: Runs after each upload completes and provides attachment/linking metadata for downstream processing.

Last updated

Was this helpful?