Feat(file): add support of the chunked file upload

[Koc]

Closes #3449.

🎥 Demo

nextcloud-chunk-upload-2026-09-28_15.26.13.mp4

What changed

File question uploads previously used a single multipart POST request per
selection. Files were limited by PHP upload limits and not paralleled. Also now we're displaying progressbar during upload.

Uploads now go through a temporary public upload share and the standard
Nextcloud WebDAV endpoint, the same mechanism used by the Files app:

1. POST .../submissions/files/{questionId}/share creates a temporary folder
   in the form owner's storage and shares it via a create-only (file drop)
   public link.
2. The file is uploaded over public.php/dav using the uploader from
   @nextcloud/files (MKCOL workspace, parallel chunk PUTs, MOVE assemble).
   Chunking requires the dav.public_shares_chunking capability; smaller
   files are sent as a plain PUT.
3. POST .../submissions/files/{questionId}/register binds the uploaded file
   to the form and question and returns uploadedFileId + uploadToken,
   which are submitted as the answer exactly as before.

Behavior changes

• Large files are uploaded in chunks with parallel requests and show per-file progress instead of a single "Uploading …" indicator.
• Uploads can be cancelled per file.
• Works for public (anonymous) submissions, since files are uploaded through a public share owned by the form owner.
• If the share or WebDAV upload fails, the client falls back to the previous multipart endpoint, so instances with disabled/restricted link shares keep working.
• Stale upload shares and folders are removed by the existing CleanupUploadedFilesJob.

API

Two new endpoints (see docs/API_v3.md / openapi.json):

• POST /api/v3/forms/{formId}/submissions/files/{questionId}/share
• POST /api/v3/forms/{formId}/submissions/files/{questionId}/register

The existing POST .../files/{questionId} multipart endpoint is unchanged
and remains supported.

Dependencies

• @nextcloud/files ^4.1.0 (new uploader, public chunking support)
• @nextcloud/vue ^9.12.0

How to test

1. Create a form with a file question and open it as a logged-in user and
   via a public share link.
2. Upload a small file and a large file (> chunk size) and verify progress
   is shown and the submission succeeds.
3. Upload two files with the same name (conflict rename) and cancel an
   upload in progress.
4. Disable link sharing (or enforce link passwords) and verify the
   multipart fallback still works.

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI (N/A)

[codecov]

Codecov Report

❌ Patch coverage is 16.47059% with 142 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
lib/Controller/ApiController.php	18.32%	107 Missing ⚠️
lib/BackgroundJob/CleanupUploadedFilesJob.php	18.18%	18 Missing ⚠️
lib/Db/FormMapper.php	0.00%	10 Missing ⚠️
lib/Db/UploadedFileMapper.php	0.00%	7 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Chartman123]

Two quick changes that came into my mind while watching the video :) I think "assembling" is too technical here for most users.

[Chartman123]

Suggested change

	t('forms', 'Assembling file {fileName}', {
	t('forms', 'Finishing upload for file {fileName}', {

[Chartman123]

Also no space before the ellipsis

Suggested change

	{{ t('forms', 'Assembling file …') }}
	{{ t('forms', 'Finishing upload…') }}

[Koc]

@Chartman123 I agree with you, but this terminology comes from the original library. Should we stay consistent in naming?

[Chartman123]

@Chartman123 I agree with you, but this terminology comes from the original library. Should we stay consistent in naming?

I've asked the designers :)

[susnux]

Why no just use NcUploadPicker ?

[Koc]

mates, that's was my very first idea. But there are few troubles with this component:

1. We need to upload large files (gigabytes) with non-stable network conditions. So would be nice to have clear progressbar per file. At the same time NcUploadPicker shows only total progress that is not enough for us

2. We have slow s3 server and assembling of the file tooks some time. So, we want to explicitly show it, not sure that NcUploadPicker supports that.

3. I like consistent UI: already uploaded files are displayed more or less same way like files in progress. We have single unified list

4. Lack of drop zone upload

Of course, in theory I can customize component. But what sense of using it if 80% code will be rewritten?

[Chartman123]

@susnux could you think of bringing these things directly into the lib?

[susnux]

We need to upload large files (gigabytes) with non-stable network conditions. So would be nice to have clear progressbar per file. At the same time NcUploadPicker shows only total progress that is not enough for us

I would say that should be aligned with design directly in the library.
There is no good reason to only add such things to Forms, instead all apps should share the same component and design here.

We have slow s3 server and assembling of the file tooks some time. So, we want to explicitly show it, not sure that NcUploadPicker supports that.

Sure we show assembling progress.

---

I think best in sense of cleanest and most consistent would be that forms just uses NcUploadPicker and does not add their own UI over it. Of cause showing the uploaded files as a list is something that should happen here as this is not part of the uploadpicker itself.
But any design changes to the uploading progress should be aligned with the designers and be implemented for the upload picker itself.

I can bring this up tomorrow with our designers if you like.

[susnux]

(sorry for the late response currently very limited time)

[Koc]

@susnux yeah, please ask designers as well