Skip to content

[feature]: allow attaching multiple files at once to a work item #9544

Description

@ebubekirdrkl

Is there an existing issue for this?

  • I have searched the existing issues

Summary

Work item attachments can only be added one file at a time. In apps/web/core/components/issues/attachment/attachment-upload.tsx the dropzone is configured with multiple: false, and onDrop takes only the first entry:

const onDrop = useCallback((acceptedFiles: File[]) => {
  const currentFile: File = acceptedFiles[0];
  ...
});

const { getRootProps, ... } = useDropzone({
  onDrop,
  maxSize: maxFileSize,
  multiple: false,
  disabled: isLoading || disabled,
});

Two consequences:

  1. The file picker does not let you select more than one file.
  2. If you drag and drop several files at once, only the first is uploaded and the rest are silently discarded — no error, no indication. That part reads more like a bug than a limitation.

Why should this be worked on?

Attaching a set of files is the normal case, not the exception: a handful of screenshots for a bug report, a log bundle, several exported documents. Right now each file is a separate drag-and-wait cycle, and dropping them together looks like it worked while quietly dropping all but one.

Backend impact

None. IssueAttachmentV2Endpoint.post already creates exactly one FileAsset and one presigned POST per call, so the client can simply fan out N calls — no bulk endpoint is needed. (Note ProjectBulkAssetEndpoint is not applicable here: it binds already-uploaded description/cover assets to an entity and has no ISSUE_ATTACHMENT branch.) The per-file size limit still applies unchanged via maxFileSize / FILE_SIZE_LIMIT.

Proposed change

In attachment-upload.tsx:

  • set multiple: true
  • iterate acceptedFiles with bounded concurrency instead of taking [0]
  • show progress as Uploading 2/5... while the batch runs
  • treat per-file failures as non-fatal: report which files were rejected (size / MIME) and keep the successful ones, rather than failing the whole batch

Happy to open the PR if maintainers are open to it.

Version

  • Self-hosted (Kubernetes), code reviewed against v1.4.0

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions