fix: remove unsupported HTML upload option from admin document picker - #215
Open
sandeep-2536 wants to merge 1 commit into
Open
fix: remove unsupported HTML upload option from admin document picker#215sandeep-2536 wants to merge 1 commit into
sandeep-2536 wants to merge 1 commit into
Conversation
Frontend advertised HTML/HTM uploads that the backend has never supported. Closes out the unfinished TODO from the original commit rather than implementing backend HTML support.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What was broken
The admin document-upload UI in
AdminContextSources.tsxadvertised HTML(
.html/.htm) as an accepted file type — in the file picker'sacceptattribute, the upload subtitle text, and the error message — but the
backend has never supported it. The multer filter and controller validation
in
admin-documents.routes.ts/adminDocuments.controller.tsonly allowPDF/TXT/Markdown/CSV, so any HTML upload was silently rejected with a 400.
Git blame confirms this wasn't accidental: the original commit's comment
explicitly says HTML support "will still be rejected by the backend until
ALLOWED_MIME... is extended (tracked as a TODO)" — planned follow-up work
that was never completed.
Fix
Removed HTML/HTM from the upload-specific UI only:
acceptattribute (.pdf,.txt,.md,.csv,.html,.htm→.pdf,.txt,.md,.csv)The separate "Paste text or HTML" feature (pasting raw text/HTML directly,
not file upload) is untouched — that's a different feature path with its
own handling and was intentionally left as-is.
Why this approach
Considered two options: (A) remove HTML from the frontend to match backend
reality, or (B) implement real backend HTML parsing/extraction. Went with
(A) because (B) would require new parsing logic, security hardening
(sanitization, since HTML is untrusted input), and test coverage — a
reasonable future feature, but not a fit for a bug-fix PR. (A) directly
closes the mismatch with no functional risk.
How this was found
Found via manual code review, not from an assigned GitHub issue.
Testing
AdminContextSources.test.tsxto assert the file input'sacceptvalue is now.pdf,.txt,.md,.csv.html/.htmno longer selectable in the file picker,subtitle/error text read correctly, PDF/TXT upload still works unchanged
pnpm exec tsc --noEmit— clean, no errorspnpm test—AdminContextSources.test.tsxpasses (9/9). 3 unrelatedtest suites (
api.test.ts,PremiumTee.test.ts,GoldenTicketDetailPage.test.tsx) fail onmainas well, due to apre-existing tooling error (
jsTokens is not a function) unrelated tothis change.