Partner testing feedback
Vermont LITEFile testing on a laptop in Chrome:
- @VTskier Dragging PDFs into the upload area one at a time did not accumulate the files. The tester had to drag all documents together to get more than one document selected. Users are likely to drag documents one at a time.
- @VTskier The tester accidentally uploaded the affidavit twice and did not see where to delete the extra copy.
Code check / feasibility
This is actionable in the LITEFile front end.
efile_app/efile/static/js/upload-documents.js currently creates a new DataTransfer inside setFiles(files) and assigns only the files from the latest selection/drop to input.files. A later drop therefore replaces the earlier pending selection rather than appending to it.
Current main does have uploaded-document removal: upload_documents.html renders a trash-icon button and upload-documents.js sends the remove action. That means the second report is primarily a discoverability problem (and may also reflect the deployed version tested). Related historical issue: #42.
Proposed behavior
- A second and later drag/drop should append files to the current pending selection rather than replace them.
- Avoid adding an exact duplicate pending file when practical (for example, matching name/size/last-modified metadata), or otherwise make duplicates obvious before upload.
- Show the pending file names before upload, with a visible way to remove one before submitting.
- Make the removal action for already-uploaded documents more discoverable than an unlabeled trash icon alone (for example, visible
Remove text on wider viewports while retaining the accessible label/icon).
- Add a browser/unit test covering two sequential drops and removal.
Acceptance criteria
- Drop PDF A, then PDF B: both are selected for upload.
- A user can remove either pending file before uploading.
- After upload, each document has an obvious removal action.
- Existing multi-file selection/drop still works.
Partner testing feedback
Vermont LITEFile testing on a laptop in Chrome:
Code check / feasibility
This is actionable in the LITEFile front end.
efile_app/efile/static/js/upload-documents.jscurrently creates a newDataTransferinsidesetFiles(files)and assigns only the files from the latest selection/drop toinput.files. A later drop therefore replaces the earlier pending selection rather than appending to it.Current
maindoes have uploaded-document removal:upload_documents.htmlrenders a trash-icon button andupload-documents.jssends theremoveaction. That means the second report is primarily a discoverability problem (and may also reflect the deployed version tested). Related historical issue: #42.Proposed behavior
Removetext on wider viewports while retaining the accessible label/icon).Acceptance criteria