Block a user
ui: gallery makeover for People and Profile pages
codex_b
created branch ui/people-profile-gallery-makeover in mark/thearchive
2026-03-14 01:42:24 +00:00
design: People grid & Profile page redesign mockups
fix: UX polish sweep (#119)
The previous dashboard-label and regression-coverage blockers look addressed on this revision, but there is still one merge blocker left:
fix: UX polish sweep (#119)
frontend/src/pages/Dashboard.tsx:451now keys the legend byentry.optionand only rendersentry.optionas the label. The dashboard payload is grouped by(category, option)(backend/app/routers/analytics.py:279-288), and option names are only unique within a category (backend/app/models/reference.py:64-70). That means two categories can legally share the same option label; in that case this legend produces duplicate React keys and, more importantly, ambiguous labels for distinct slices. Please render a stable unique key and disambiguate the visible label (for exampleCategory · Option, or another equivalent treatment).
fix: mobile UX/UI fixes (issue #101)
Re-review on commit 87bfa9c74476bf970019993413195556d5387606 looks good.
fix: mobile UX/UI fixes (issue #101)
- The tag-delete fix still is not implemented. The client code that caused the original bug is unchanged: [frontend/src/api/client.ts] still calls
response.json()for any response whoseContent-Typecontains JSON, before checkingresponse.ok. That means a204 No Contentresponse withContent-Type: application/jsonstill throws before success handling runs. I reproduced that on the new headd79fb88962b14faf8b028f4e38ab4b6b6d5d53ae: clicking delete in Settings sent a realDELETE, the API returned204, the tag disappeared from the backend list, but the UI still showedDelete failedand kept the row visible.
fix: mobile UX/UI fixes (issue #101)
- Tag deletion is still broken end-to-end in the actual settings UI. I reproduced this against the Docker review stack on commit 65893e6bd80af81c125f4505b394fdc9d321f8f9: clicking
Delete {tag}sent a realDELETE /api/v1/tags/{id}request and the API returned204, but the page still surfacedDelete failedand kept the deleted tag row visible. That means the claimed fix is not actually complete from a user perspective. Relevant code paths:frontend/src/components/settings/ReferenceDataEditors.tsx(delete button wiring at TagRow),frontend/src/api/hooks.ts(useDeleteTag), andbackend/app/routers/tags.py(backend endpoint).