[feature]: allow text/html attachments now that script-capable types are served as downloads

Is there an existing issue for this?

• I have searched the existing issues

Summary

text/html is missing from ATTACHMENT_MIME_TYPES (apps/api/plane/settings/common.py:457), so uploading an .html file to a work item fails with 400 {"error": "Invalid file type."} from IssueAttachmentV2Endpoint.post (apps/api/plane/app/views/issue/attachment.py:105).

This is inconsistent with the rest of the allowlist, which already permits several types that are equally or more script-capable: image/svg+xml (:462), text/javascript (:534), text/xml, application/xml, text/css.

Why should this be worked on?

HTML is a common artifact people want to attach to a work item:

• test / coverage / audit reports (Playwright, Jest, JaCoCo, Lighthouse, k6)
• exported emails or saved pages attached as evidence to a bug report
• static exports from BI or log tools

Today the workaround is to zip the file or rename it to .txt, which loses the extension and makes the attachment awkward to consume.

Security context

Historically the obvious objection would be stored XSS — an uploaded HTML file rendered inline from an origin shared with the app. That hole has already been closed by #9312 (GHSA-ch8j-vr4r-qf6h): SCRIPT_CAPABLE_MIME_TYPES (apps/api/plane/settings/common.py:550) already includes text/html (:555), and all three previously-inline download paths now force Content-Disposition: attachment for those types:

• GenericAssetEndpoint.get — apps/api/plane/api/views/asset.py:452-460
• StaticFileAssetEndpoint.get — apps/api/plane/app/views/asset/v2.py
• EntityAssetEndpoint.get — apps/api/plane/space/views/asset.py

So allowing text/html on upload does not reintroduce a render path — the browser would download it, never execute it. The precedent is image/svg+xml: an equally script-capable type that is already allowed for upload and protected by exactly this mechanism. text/html would be strictly no worse.

Proposed change

Add to ATTACHMENT_MIME_TYPES:

    "text/html",
    "application/xhtml+xml",

Both are already members of SCRIPT_CAPABLE_MIME_TYPES, so no other change is required.

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

Version

• Self-hosted (Kubernetes), behavior verified against v1.2.0 and code reviewed against v1.4.0

Start with ATTACHMENT_MIME_TYPES in apps/api/plane/settings/common.py:457 and the upload validation in apps/api/plane/app/views/issue/attachment.py:105. Check the existing SCRIPT_CAPABLE_MIME_TYPES entry at common.py:550 and the three asset download handlers named in the issue. Done means the proposed HTML MIME types are accepted for attachments while downloads retain attachment disposition.