What: The "View Deliveries" action on the Events page navigates to the Deliveries page with an event_id query param, but nothing downstream reads or applies it — the user always sees the full, unfiltered delivery list instead of that event's deliveries.
Where:
resources/js/Pages/Events/Index.vue:544-546 — viewDeliveries(event) calls router.get(route('deliveries'), { event_id: event.id }).resources/js/Pages/Deliveries/Index.vue:386-392 — the page's own filters ref only tracks status, endpoint_id, event_name, from_date, to_date; there is no event_id field anywhere on this page.app/Http/Controllers/DashboardController.php:74-93 (deliveries()) — only reads/applies status and endpoint_id ($request->only(['status', 'endpoint_id']) on line 92); event_id is never read or applied to the query.
Why it matters: This is a broken control that looks functional but silently does nothing, in the same family as the non-functional Retry buttons (#78). A user clicking "View Deliveries" from a specific event expects to see that event's delivery history, but instead gets every delivery across every event with no error or indication the filter was dropped. Note the backend already has correct precedent for this exact filter — app/Http/Controllers/Api/DeliveryController.php:34-35 filters by event_id for the REST API — it just was never wired into the dashboard controller or the Vue page's filter state. This is also distinct from #81 (which covers the Deliveries page's own event_name/date-range fields being ignored): that's a different parameter from a different page, and fixing #81 would not fix this.
Suggested fix: Add event_id handling to DashboardController::deliveries() (mirror the API controller's where('event_id', ...) and include it in $request->only([...])), add an event_id field to the filters ref/initial state in Deliveries/Index.vue, and surface the active filter in the UI (e.g. a dismissible "Filtered by event: X" chip).
What: The "View Deliveries" action on the Events page navigates to the Deliveries page with an
event_idquery param, but nothing downstream reads or applies it — the user always sees the full, unfiltered delivery list instead of that event's deliveries.Where:
resources/js/Pages/Events/Index.vue:544-546—viewDeliveries(event)callsrouter.get(route('deliveries'), { event_id: event.id }).resources/js/Pages/Deliveries/Index.vue:386-392— the page's ownfiltersref only tracksstatus,endpoint_id,event_name,from_date,to_date; there is noevent_idfield anywhere on this page.app/Http/Controllers/DashboardController.php:74-93(deliveries()) — only reads/appliesstatusandendpoint_id($request->only(['status', 'endpoint_id'])on line 92);event_idis never read or applied to the query.Why it matters: This is a broken control that looks functional but silently does nothing, in the same family as the non-functional Retry buttons (#78). A user clicking "View Deliveries" from a specific event expects to see that event's delivery history, but instead gets every delivery across every event with no error or indication the filter was dropped. Note the backend already has correct precedent for this exact filter —
app/Http/Controllers/Api/DeliveryController.php:34-35filters byevent_idfor the REST API — it just was never wired into the dashboard controller or the Vue page's filter state. This is also distinct from #81 (which covers the Deliveries page's ownevent_name/date-range fields being ignored): that's a different parameter from a different page, and fixing #81 would not fix this.Suggested fix: Add
event_idhandling toDashboardController::deliveries()(mirror the API controller'swhere('event_id', ...)and include it in$request->only([...])), add anevent_idfield to thefiltersref/initial state inDeliveries/Index.vue, and surface the active filter in the UI (e.g. a dismissible "Filtered by event: X" chip).