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.

Default document type

• Type: selection

• Purpose: Select a document type as a default. If you want the user to select you can use the Allowed document types property.

Allowed document types

• Type: multi-selection

• Purpose: Select allowed document types.

Document Type selection

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.
Visible	Shows a dropdown that is pre-populated from the allowed document types	Let users override the document type on demand.

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

Allowed extensions

• 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 Blocked extensions for finer control.

Blocked extensions

• 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.

Max file size (MB)

• 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.

Max files

• 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.

Local mode

• Type: boolean.

• Purpose: Skips the server upload entirely and lets you process files on the client via OnUpload.

• Behavior: The control still shows the queue and status chips. For each file, OnUpload receives the raw file, full text content (rawData), line arrays (rawLines), CSV-parsed rows (csvLines) and extension metadata. If OnUpload returns false, the item is canceled. Otherwise it is marked as done locally; no attachment is created, no linking happens, and OnUploaded is not fired.

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.