KamoCRM

Attachments sit above the body, as the files themselves

Featurekamo-internal
관련 상품
2026년 9월 24일 오전 4:42 UTC
이름 *
Kamo
뚱 베어
2dffd64

An email whose only content was a PDF had no way to open or download the file: the paperclip showed on the list row, and the reading pane showed nothing. EmailService had marked the PDF inline because the Gmail app gave it a Content-ID (fixed there in 0de0823); the pane dropped every inline part without asking whether the body actually painted it. The rule now lives in one place, listedAttachments: a part stays out of the list only when the HTML body references its cid:. The reading pane, the lead timeline and forwarding all use it, so a forwarded message no longer silently drops that file either. It does not trust the server's flag, which bodies cached in the browser still carry from before the fix. The sanitizer resolves cid: references with the same normalization, so anything left out of the list is always something the body shows. The attachment shelf, first thing under the header: - each file is a card showing the file itself: page one of a PDF (with its page count), the photo, or the type's glyph on blank paper - one click previews in a full-screen viewer: PDF through pdf.js with zoom and a page counter, images fit-to-screen with click-to-zoom, video and audio players, text, and CSV/TSV as a table; the arrow keys and a filmstrip move between files - downloads go through fetch, carrying the per-tab session header a bare <a download> never could, with a progress ring and a drawn tick - "Download all" hands every file over as one .zip written in the browser - keyboard-first, reduced motion honoured, axe clean; two cards per row in a narrow pane

모든 변경 사항

배송을 보는 것과 같이?

모든 것이 자신의 작업 공간에서 도착합니다. 무료 플랜을 시작하고 이 페이지를 다시 한 달에 읽으십시오.

무료 영원히 시작가격 비교