[WC-3361] FileUploader: enhance limits and feedback#2208
Conversation
430b80b to
4d8b53f
Compare
a444b83 to
7d054a3
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
9fe41dd to
09489e2
Compare
This comment was marked as outdated.
This comment was marked as outdated.
AI Code Review
What was reviewed
Skipped (out of scope): Findings
|
- Show "Maximum file count of X reached" message when dropzone is disabled - Make maxFilesPerUpload optional (empty/0 = unlimited) - Add maxFilesPerBatch property to cap server commits per drop event - Split drops by remaining capacity — excess files shown as errors, not silently rejected - Auto-retry limit/batch-exceeded files when capacity is freed - Batch/limit-exceeded files survive dismissValidationErrors and re-queue correctly - Retry order matches visual list order (newest first) - Reorder file list: accepted files above rejected files
d06abf7 to
8fe5f51
Compare
AI Code Review
What was reviewed
Skipped (out of scope):
Findings🔶 Medium —
|
- Add "queued" and "rejected" statuses; remove "new", "removedAfterError" - Remove errorType field and dismissValidationErrors - maxFilesPerBatch (XML) → maxConcurrentUploads (TS) - maxFilesPerUpload (XML) → maxTotalFiles (TS) - processDrop is pure classifier; two reactions drain the queue - Add uploadQueuedMessage XML property - Remove uploadBatchLimitExceededMessage XML property
Pull request type
Bug fix + Feature (behavior change — non-breaking)
Description
When the file upload limit was reached, the dropzone silently turned grey with no explanation. Dropping more files than the limit rejected the entire batch. There was no proper upload queue — excess files were marked as errors and "retried" via a promotion mechanism, conflating queueing with error state.
This PR addresses:
maxFilesPerBatch) controls how many files upload simultaneously. Excess files queue and drain automatically.maxFilesPerUploadproperty is now optional — empty or 0 means unlimited.No longer depends on WC-3363. The
dismissValidationErrorsmethod was removed as part of this PR — rejected files are a distinct state from validation errors and are not dismissable. WC-3363 can merge independently.What should be covered while testing?
Setup: File Uploader widget, files mode. Start with "Maximum number of files" = 5, "Maximum concurrent uploads" = 2.
File limit feedback:
Unlimited behavior:
5. Set total limit = 0 → dropzone never disables regardless of file count
6. Leave total limit empty → same as 0, unlimited
Concurrent upload queue:
7. Set concurrent uploads = 2, drop 5 files → exactly 2 show "Uploading..." with progress bar, remaining 3 show "Waiting..." without progress bar
8. Wait for 1 upload to complete → next queued file automatically starts uploading (now shows "Uploading...")
9. Leave concurrent uploads empty → all dropped files start uploading simultaneously
Total limit with auto-promotion:
10. Set total limit = 3, concurrent uploads = unlimited. Drop 5 files → 3 upload, 2 show as rejected with "Maximum file count of 3 reached."
11. Remove 1 uploaded file → oldest rejected file automatically starts uploading
12. Let an upload fail → that file shows error; oldest rejected file automatically starts uploading
List ordering:
13. Upload a mix of valid and invalid files → successful uploads appear above rejected files
Other:
14. Read-only mode → dropzone not rendered, no regression
15. Image upload mode → same queue and limit behavior applies