Feedback

Hi maintainers — thanks for Quackback; we run it in production and it's been great. One gap we've hit versus dedicated bug-report tools: when an end-user reports a bug through the widget, there's no built-in way for them to attach an *annotated screenshot*, and no automatic capture of the technical context an engineer needs to reproduce it. A "it's broken" report often arrives with none of the reproduction signal. We've built this as a fork patch and wanted to gauge whether it's something you'd welcome upstream **before** investing in polishing it to your conventions. **What it does** — a "report a bug" widget entry (shortcut + SDK command) that captures the page as an image the user can annotate (pen/arrow/rectangle/redact) + a one-line summary + one-tap impact; plus automatic privacy-first capture of route, build/commit id, a correlation/request id (join client↔server logs), tenant id, a console/error ring buffer, and the last failing request — every string deep-masked client-side **before it leaves the browser**. DOM-based (shadow-DOM-friendly), lazy-loaded, behind a config flag (default **off**). The structured context rides the existing post flow + surfaces on the `post.created` webhook. **Why it fits** — raises report rate (low friction) + makes each report rich enough for automated triage/AI — squarely the feedback-tool value prop; additive + flag-gated (no behavior change). **Questions** — (1) in-core or intentionally out of scope? (2) preferences on capture approach / masking / webhook shape before a PR? (3) same appetite as #118 ("Add the image as an attachment")? Happy to open a PR adapting to your conventions if there's interest. Thanks!

**Context.** We run Quackback with the Help Center doubling as an internal team docs hub alongside the public KB. (Thanks for merging #325 — the inbound-email body fetch — much appreciated!) **The gap.** Today an HC category is either **public** (`isPublic = true`) or **internal** (visible to *all* authenticated team members). There's no way to make a category readable by **admins only** — e.g. ops notes, review cadences, or non-sensitive product-decision logs that regular members shouldn't see. Authenticated reads currently resolve to both roles, so "internal" means "everyone on the team". **Proposal — a 3rd visibility tier via an additive `admin_only` boolean on categories:** - A mandatory DB `CHECK (NOT (admin_only AND is_public))` — the two are mutually exclusive (a category can't be both admin-only and world-public). - `admin_only` applies to the **whole descendant subtree** (computed app-side at read time), so a child under an admin-only parent is hidden too. - A **fail-closed** `includeAdminOnly` read parameter (default **false**) wired from the *verified* role at every read surface (server-fn, REST, MCP), so a forgotten call site hides content rather than leaking it. - Read-side defense-in-depth: the anonymous/public consumers also exclude the admin-only subtree, so a write-path regression can't surface admin-only content publicly. **Why a discussion first.** It's an opinionated feature — a visibility/security boundary rather than a bugfix — so before investing in a polished PR we'd like to gauge interest and design preferences: 1. Is an admin-only category tier something you'd consider upstream? 2. If so, any preferences on the shape — column naming, whether the read gate belongs in the domain layer vs per-surface, how you'd want it tested? We have a working implementation on our fork (built on top of #325) and are happy to open a PR adapting to your conventions + test style if there's appetite. Thanks!

If the admin enables the Rich Text Editor, it should remain in a fixed position. The "floating" editor that appears upon text selection often causes compatibility issues across different browsers. Check: https://github.com/QuackbackIO/quackback/issues/119 **Please provide an option to pin the editor toolbar either to the top or bottom of the post area.**

Adding images to a post becomes complicated with a rich editor. I think the best way to add images is to attach them to the bottom of the post, like canny.io does. Also, integration with a third-party image storage service for managing added images would be great.

Hi maintainers — thanks for Quackback; we run it in production and it's been great. One gap we've hit versus dedicated bug-report tools: when an end-user reports a bug through the widget, there's no built-in way for them to attach an *annotated screenshot*, and no automatic capture of the technical context an engineer needs to reproduce it. A "it's broken" report often arrives with none of the reproduction signal. We've built this as a fork patch and wanted to gauge whether it's something you'd welcome upstream **before** investing in polishing it to your conventions. **What it does** — a "report a bug" widget entry (shortcut + SDK command) that captures the page as an image the user can annotate (pen/arrow/rectangle/redact) + a one-line summary + one-tap impact; plus automatic privacy-first capture of route, build/commit id, a correlation/request id (join client↔server logs), tenant id, a console/error ring buffer, and the last failing request — every string deep-masked client-side **before it leaves the browser**. DOM-based (shadow-DOM-friendly), lazy-loaded, behind a config flag (default **off**). The structured context rides the existing post flow + surfaces on the `post.created` webhook. **Why it fits** — raises report rate (low friction) + makes each report rich enough for automated triage/AI — squarely the feedback-tool value prop; additive + flag-gated (no behavior change). **Questions** — (1) in-core or intentionally out of scope? (2) preferences on capture approach / masking / webhook shape before a PR? (3) same appetite as #118 ("Add the image as an attachment")? Happy to open a PR adapting to your conventions if there's interest. Thanks!

**Context.** We run Quackback with the Help Center doubling as an internal team docs hub alongside the public KB. (Thanks for merging #325 — the inbound-email body fetch — much appreciated!) **The gap.** Today an HC category is either **public** (`isPublic = true`) or **internal** (visible to *all* authenticated team members). There's no way to make a category readable by **admins only** — e.g. ops notes, review cadences, or non-sensitive product-decision logs that regular members shouldn't see. Authenticated reads currently resolve to both roles, so "internal" means "everyone on the team". **Proposal — a 3rd visibility tier via an additive `admin_only` boolean on categories:** - A mandatory DB `CHECK (NOT (admin_only AND is_public))` — the two are mutually exclusive (a category can't be both admin-only and world-public). - `admin_only` applies to the **whole descendant subtree** (computed app-side at read time), so a child under an admin-only parent is hidden too. - A **fail-closed** `includeAdminOnly` read parameter (default **false**) wired from the *verified* role at every read surface (server-fn, REST, MCP), so a forgotten call site hides content rather than leaking it. - Read-side defense-in-depth: the anonymous/public consumers also exclude the admin-only subtree, so a write-path regression can't surface admin-only content publicly. **Why a discussion first.** It's an opinionated feature — a visibility/security boundary rather than a bugfix — so before investing in a polished PR we'd like to gauge interest and design preferences: 1. Is an admin-only category tier something you'd consider upstream? 2. If so, any preferences on the shape — column naming, whether the read gate belongs in the domain layer vs per-surface, how you'd want it tested? We have a working implementation on our fork (built on top of #325) and are happy to open a PR adapting to your conventions + test style if there's appetite. Thanks!

If the admin enables the Rich Text Editor, it should remain in a fixed position. The "floating" editor that appears upon text selection often causes compatibility issues across different browsers. Check: https://github.com/QuackbackIO/quackback/issues/119 **Please provide an option to pin the editor toolbar either to the top or bottom of the post area.**

Adding images to a post becomes complicated with a rich editor. I think the best way to add images is to attach them to the bottom of the post, like canny.io does. Also, integration with a third-party image storage service for managing added images would be great.