feat(web): mount the feedback launcher in the admin panel #488

Merged

Claude-Run merged 1 commit from feat/BUNYIP-370-feedback-everywhere into main

2026-08-06 05:26:31 +02:00

Claude-Run commented

2026-08-06 05:21:27 +02:00

Member

The floating "Have feedback?" launcher was mounted by dashboard_shell and by public_shell (gated by show_feedback), but admin_shell rendered no feedback affordance at all, so the entry point existed on the user dashboard and the marketing pages while every admin screen had none. The admin nav's "Feedback" item is the review queue for feedback other people sent, not a way to send any.

admin_shell now mounts the same feedback_launcher() component the user dashboard uses, so it reaches the existing /feedback form, carries the originating admin path through data-feedback-link -> ?from= -> the hidden page_path input, and submits through the existing calls::submit_feedback path. No new backend and no new route.

Guards: every_authenticated_shell_mounts_the_feedback_launcher renders both authenticated shells and fails if either one drops the launcher, so a future shell that forgets it cannot land silently. admin_panel_submission_goes_through_the_existing_feedback_path drives a real multipart body carrying page_path=/admin/users through read_feedback_multipart, and admin_paths_round_trip_through_the_form covers the ?from= sanitize plus hidden-field round trip for admin paths.

The login / register / consent flow and /feedback itself keep the launcher off, which is the deliberate minimal-chrome posture those pages already had.

#BUNYIP-370

The floating "Have feedback?" launcher was mounted by `dashboard_shell` and by `public_shell` (gated by `show_feedback`), but `admin_shell` rendered no feedback affordance at all, so the entry point existed on the user dashboard and the marketing pages while every admin screen had none. The admin nav's "Feedback" item is the review queue for feedback other people sent, not a way to send any. `admin_shell` now mounts the same `feedback_launcher()` component the user dashboard uses, so it reaches the existing `/feedback` form, carries the originating admin path through `data-feedback-link` -> `?from=` -> the hidden `page_path` input, and submits through the existing `calls::submit_feedback` path. No new backend and no new route. Guards: `every_authenticated_shell_mounts_the_feedback_launcher` renders both authenticated shells and fails if either one drops the launcher, so a future shell that forgets it cannot land silently. `admin_panel_submission_goes_through_the_existing_feedback_path` drives a real multipart body carrying `page_path=/admin/users` through `read_feedback_multipart`, and `admin_paths_round_trip_through_the_form` covers the `?from=` sanitize plus hidden-field round trip for admin paths. The login / register / consent flow and `/feedback` itself keep the launcher off, which is the deliberate minimal-chrome posture those pages already had. #BUNYIP-370

Claude-Run added 1 commit

2026-08-06 05:21:27 +02:00

feat(web): mount the feedback launcher in the admin panel

E2E PR gate / E2E / PR gate (pull_request) Successful in 25s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 4m38s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

c01c074d5c

The floating "Have feedback?" launcher was mounted by `dashboard_shell` and by `public_shell` (gated by `show_feedback`), but `admin_shell` rendered no feedback affordance at all, so the entry point existed on the user dashboard and the marketing pages while every admin screen had none. The admin nav's "Feedback" item is the review queue for feedback other people sent, not a way to send any.

`admin_shell` now mounts the same `feedback_launcher()` component the user dashboard uses, so it reaches the existing `/feedback` form, carries the originating admin path through `data-feedback-link` -> `?from=` -> the hidden `page_path` input, and submits through the existing `calls::submit_feedback` path. No new backend and no new route.

Guards: `every_authenticated_shell_mounts_the_feedback_launcher` renders both authenticated shells and fails if either one drops the launcher, so a future shell that forgets it cannot land silently. `admin_panel_submission_goes_through_the_existing_feedback_path` drives a real multipart body carrying `page_path=/admin/users` through `read_feedback_multipart`, and `admin_paths_round_trip_through_the_form` covers the `?from=` sanitize plus hidden-field round trip for admin paths.

The login / register / consent flow and `/feedback` itself keep the launcher off, which is the deliberate minimal-chrome posture those pages already had.

#BUNYIP-370