php-bug-catcher / bug-catcher / 33502827332

84%

main: 84%

push

github

feat(detail): fix it / archive it buttons in the detail header

The status buttons of the log list are now next to the request URL on the detail
page, so an error can be cleared from the page you inspect it on instead of
going back to the list.

They cannot reuse LogList\RecordLog::clearOne() over HTTP: it reads the record
and the status filter from live props, which only exist on a live request. A
thin controller posts to a route instead.

Two details the list does not have to care about:

  * `firstOccurrence` is transient - the list computes it while grouping the
    hundred rows it loaded, and on the detail page it is null. The controller
    therefore looks the oldest occurrence of the hash up in the database, or
    only the record on screen would change status and the error would stay in
    the list.
  * the status ends up interpolated into DQL by getUpdateStatusQB(), so the
    route pins it to `resolved|archived` rather than accepting any string.

The detail page is opened from the list with target="_blank", so the buttons
submit through fetch() and then close their own tab. A browser only lets a
script close a tab while it still holds a single history entry, and a plain POST
plus redirect would spend that entry. If the close is refused anyway - direct
visit, restored tab - the page reloads so the new status stays visible; if the
request fails, the form falls back to a normal submit. XHR gets 204 back, a
normal post still redirects to the detail page.

The test app had no firewall outside ^/api, which left is_granted() always false
and role protected pages untestable. It gets one scoped to ^/detail - narrow on
purpose, the admin tests rely on /admin staying unsecured.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

15 of 16 new or added lines in 1 file covered. (93.75%)

881 of 1047 relevant lines covered (84.15%)

6.87 hits per line