#443 dash: "Copy details" button on each pending-approval card

[Anonymous]

Originally created by: fu351

Each pending-approval card in the dashboard (renderPending, src/doberman/dash/app.py:448-544) shows the risk badge, summary, expiry, reason codes, explanation and the Approve/Deny buttons, all built with createElement/textContent. There's no way to grab those fields to paste into a chat or an issue except retyping them.

What to do

1. In the per-row loop of renderPending, add a <button type="button" class="btn btn-copy">Copy details</button> next to Approve/Deny.
2. On click, navigator.clipboard.writeText(JSON.stringify({id, tier, risk, action_type, reason_codes, explanation}, null, 2)) built from the row the server sent. Wrap it in try/catch, the same defensive shape the file already uses for sessionStorage (lines 306-314); the clipboard API is unavailable in some contexts and a failure must not break the card.
3. Only fields /api/pending already serves (_pending_row, line 755 onward) go into the copied text. Never add a raw target or path; the server redacts for a reason.
4. Test in tests/unit/test_dash_polish.py: the served shell contains btn-copy (same style as the existing badge-class assertions).

Heads-up: two dashboard PRs are in flight (#401 strictness-mode control, [#415] per-project title); both edit dash/app.py's top bar. Branch from a fresh main, stay out of .topbar-right, and expect a small rebase if they land while you work.

[Anonymous]

Originally posted by: slegarraga

Thanks again for pointing me here! I checked the current state and don't see an assignee or an active PR, so I'll pick this up now.

I'll keep the copied payload strictly limited to the six already-redacted fields served by /api/pending, make clipboard failure fully non-disruptive to the card's existing actions, and add focused regression coverage. I'll link the PR here once the implementation and tests are ready.

[Anonymous]

Originally posted by: slegarraga

The implementation is ready for review in [#498]. It keeps the clipboard payload strictly allowlisted to the six redacted fields from /api/pending, catches both unavailable and rejecting clipboard APIs, and leaves the existing Approve/Deny flow untouched.

I added focused security regression coverage, the README update, and the required changelog fragment. All six CI checks are green across Linux 3.11–3.13, Windows 3.12, package smoke, and secret scan. Thanks again for the thoughtful pointer to this issue!

[Anonymous]

Ticket changed by: vinayjagan03

• status: open --> closed