Backlog
16Under consideration
Import common document attachments as PDFs (convert Office docs)
When an email has an attachment that's a common document type — Word (.doc/.docx), Excel (.xls/.xlsx), PowerPoint (.ppt/.pptx), and similar — let the user import it into the project as a redactable PDF. We already support importing PDF attachments directly into a project. The gap is the non-PDF document types: they'd need to be converted to PDF on import (a conversion step we don't have yet) before they can enter the redaction workflow. Goal: bring more attachment content into redaction — a user shouldn't have to download a Word/Excel attachment, convert it elsewhere, and re-upload it. Pick it from the attachment, we convert + import it as a PDF document in the project. Notes / scope: Reuse the existing 'import attachment as document' flow; add a convert-to-PDF stage for supported non-PDF types. Decide the supported set (Office formats first; maybe images, .rtf, .txt, .eml later). Conversion likely belongs on the worker / a conversion service (LibreOffice headless or similar) — needs design.
Wide tables are silently cut off in exported PDFs
When an item contains a table wider than the printed page, the exported PDF silently loses the columns that overflow the right-hand margin. The customer gets a document that looks complete but isn't, with no warning anywhere. What happens We render items to PDF at A4 with 1cm margins. Chromium shrinks over-wide content to fit up to a bounded factor and then simply clips whatever is left. The clipped text is not drawn on the page and is not in the PDF's text layer, so it cannot be found, redacted, searched or recovered. Real example A delivery-exception report pasted from Excel into Outlook: 14 columns, roughly 1850px wide. The exported PDF prints as far as "Address 2" plus two characters of the postcode. Category, Issue, Repeat, the free-text Comment and Closed are gone from every row. One cell that reads Admin-Mitcham-039-Customer contacted for delivery instructions not followed on 23/01... prints as Admin-Mitcham-0 and stops. Why it matters This is a data-completeness problem on a disclosure product. Items are exported for DSARs and legal disclosure, so handing over a document with content missing is worse than failing loudly — and nothing currently tells anyone it happened. It also produces a confusing second-order effect: a term can be redacted successfully in the interface while no black box ever appears, because the text it matched is not on the page at all. Suggested direction Detect and flag first — cheap, and turns a silent loss into a visible one. At conversion, compare the rendered text against the source and warn on the item when content did not fit. Then remedy — render items that overflow in landscape, or scale the page down further for wide content, so the columns actually print. Raised from support conversation 583, where the missing text was found while investigating a separate export-gate problem (now fixed).
Export the attachments with the PDFs
Export the attachments with the PDFs as an option, unredacted, so you can then do something about them afterwards. Somehow link them in the PDF.
Attachment Manager
Add a view to view all attachments at a glance in emails, and eventually import them once this is supported.
Apply wordlist per file
It’d be great to be able to quickly apply word list redaction on a per mail/file basis. As we’re processing large mailboxes, the PDFs have not been rendered for most items, so we are having to do them one at a time.
Open and import password-protected PDFs
Password-protected PDF attachments now show a clear "password-protected" notice instead of locking the page up — but there's still no way to get at the contents. Add a way to unlock these files: prompt for the password when previewing or importing, then store an unlocked copy so the document behaves like any other — preview, search, redact and export. Raised off the back of the locked-out display bug report.
Add "To" column
The display at the moment does not have a “To” column. Can this be added? This is useful especially for “sent” emails.
Filter from a selected item (right-click “See all from this sender / tag / date”)
Add a quick way — e.g. a right-click context menu on an item — to filter the list by an attribute of the currently selected item, without typing it out manually. "See all items from xyz@abc.com" — applies a From filter using the selected item's sender. "See all items with tag 'sent'" — applies a tag filter. "See all items received on 20/08/2025" — applies a date filter. Reported via support as a faster way to pivot from one item to everything related to it.
Link imported attachments to their source email (cross-navigation + hierarchical export)
When you import an email attachment into a project as a document (see the “Import common document attachments as PDFs” work), the imported PDF and the email it came from should stay linked and easy to move between — both in the app and in the export. 1. Cross-navigation in the app From the imported document's PDF view, a link back to the source email it was extracted from. From the email, a link out to its imported attachment document(s). Make jumping between the two effortless — you're often redacting the email and its attachment as one piece of work. 2. Hierarchical export On export, the imported attachment PDF should sit “underneath” its parent email — a parent/child hierarchy rather than a flat list, so the relationship is obvious when someone reviews the exported bundle. The structure should make clear “this PDF came from that email”. 3. Linked attachment inside the exported PDF In the exported email PDF, embed a link / attached document pointing to the imported attachment PDF, so a reviewer can jump straight to it from within the email export. Notes / scope: The data link already exists — imported documents store a source_email_id back to their email — so this is mostly UI navigation + export-structure work, not new plumbing. Depends on the convert-standard-docs import feature; logged separately to keep that one focused. Export piece needs design: how the hierarchy is represented (folder nesting in the ZIP, ordering in a combined PDF) and how the in-PDF link/attachment is generated (pdf-lib link annotation or embedded file).
Filter the email list by attachment type (e.g. contains PDF)
In the email list, let users filter by attachment type — e.g. show only items whose attachments contain a PDF, or a Word doc, an image, a spreadsheet, etc. Why: When you're redacting a large mailbox, the sensitive material often lives in attachments of a specific kind. Being able to narrow the list to "items with a PDF attachment" (or Word / Excel / image) makes it much faster to find and work through the documents that actually need redacting, rather than scrolling every item. Scope / notes: Add an attachment type dimension to the existing email-list filter UI. Match on attachment MIME type / extension — group into friendly buckets (PDF, Word, Excel, PowerPoint, image, archive, other). "Contains" semantics: an item matches if any of its attachments is of the selected type. Possibly combine with a simple "has any attachment" toggle. Pairs naturally with the "import common document attachments as PDFs" work — once more types are redactable, filtering to them matters more.
Next up
1Committed and queued
In Progress
Actively being built
No In Progress issues
Done
42Recently shipped
Search to Redact Functionality
Being unable to search for specific keywords or specific emails was really problematic. I ended up exporting things back into outlook, deleting and sorting email chains and reimporting - which was time consuming.
The ability to share Projects
Allows you to share projects with other users on the platform.
Upload Attachments from Emails
Grab attachments from emails, convert to PDF and then allow to redact.
Never-redact list: protect specific names from every redaction pass
A list of names, addresses or terms that must never be redacted, regardless of what a word list, Auto-Redact or Search & Redact would otherwise match. Why The requester's own name has to survive redaction, and so do things like the organisation's name or a case reference. Today a broad word list or Auto-Redact can catch them, and the only fix is to spot it and remove the redaction by hand — on every item. The ask A project-level "never redact" list that every redaction method respects. Simpler and independent of automatic name discovery, and useful on its own. Asked twice in support ("How do I use a whitelist of names that should not be redacted ever?" and "How do I whitelist certain names and email addresses which I don't want to redact?"). Logged from conversations 67 and 66.
Blank Pages at the beginning of PDF Exports
Fixed and deployed. Blank pages at the start of an exported PDF were caused by how documents authored in Word/Outlook declare their page layout: it forced a page break that left the document header alone on the first page, with the content pushed onto the next page (and, for multi-section messages such as bounce notifications, over several pages). The exporter no longer honours that author-supplied page layout, so the header and content now start together on page one. Genuine, deliberate page breaks are still respected. Note: this applies to documents processed from now on. PDFs that were already exported keep their existing layout — re-exporting the affected documents produces the corrected version.
[bug] Password protected PDF attachments cause locked out display
When a PDF attachment is password protected, the page prompts you for a password. When this is cancelled, it just prompts again, soft locking the page until you refresh.
Redaction Word Lists
I'd find it incredibly useful to be able to upload a list of pre-defined names, ideally via a CSV file, for the Search to Redact functionality. This would allow me to efficiently redact multiple specific names across documents, saving significant time compared to manually entering each name individually.
Embedded Image Redaction
Redact text and other content within images.
Add Header vs Body Filtering to Email Filter
This would be incredibly useful for our SAR triage process. We need more refined filtering options, like filtering on header vs. body, to effectively narrow down entire mailboxes and identify relevant emails before the redaction stage.
Add "unprocessed" filter in the email list
We currently have filters for the statuses of emails. However, we would like to be able to filter by “unprocessed” so you can see what you haven’t done yet.