## 배경 사용자가 등록한 곡 오류 신고(`song_reports`)를 운영자가 검토하고 승인/거부 처리할 수 있는 관리자 전용 페이지가 필요하다. 관리자가 아닌 사용자는 페이지·API 모두 접근할 수 없도록 차단한다. ## 구현 내용 - [ ] 관리자 전용 라우트 신규 생성 (예: `/admin/reports`) - [ ] 관리자 권한 식별 메커니즘 정의 및 적용 (예: `users` 테이블의 `role` 컬럼 또는 별도 `admins` 테이블 — 현황 확인 후 결정) - [ ] 비관리자 접근 시 차단/리다이렉트 처리 (페이지 + API 양쪽) - [ ] `GET /api/admin/reports` — 모든 신고 조회 (필터: 상태 `pending`/`applied`/`rejected`, 최신순, 곡 정보 JOIN) - [ ] `PATCH /api/admin/reports/[id]` — 상태 변경 (`applied` / `rejected`) - [ ] 승인(`applied`) 시 `songs` 테이블의 해당 필드를 `suggested_value`로 업데이트하는 로직 (단일 트랜잭션 또는 RPC) - [ ] 관리자 페이지 UI: 신고 리스트(상태 탭/필터), 항목별 [승인/거부] 액션 버튼, 변경 후 invalidate - [ ] 처리 이력을 위해 `reviewed_by`, `reviewed_at` 컬럼 추가 검토 (현재 스키마 확인 필요) ## 참고 - 사용자 측 신고 기능은 #217 (등록), #219 (자기 신고 조회/삭제) 에서 구현됨 - 본 작업은 운영자 관점의 처리 워크플로우. 관리자 권한 식별 방식이 가장 큰 결정 포인트 (Supabase RLS · custom claim · users.role 컬럼 중 택 1) — `/spsc`에서 현재 스키마/세션 구조 확인 후 확정
배경
사용자가 등록한 곡 오류 신고(
song_reports)를 운영자가 검토하고 승인/거부 처리할 수 있는 관리자 전용 페이지가 필요하다.관리자가 아닌 사용자는 페이지·API 모두 접근할 수 없도록 차단한다.
구현 내용
/admin/reports)users테이블의role컬럼 또는 별도admins테이블 — 현황 확인 후 결정)GET /api/admin/reports— 모든 신고 조회 (필터: 상태pending/applied/rejected, 최신순, 곡 정보 JOIN)PATCH /api/admin/reports/[id]— 상태 변경 (applied/rejected)applied) 시songs테이블의 해당 필드를suggested_value로 업데이트하는 로직 (단일 트랜잭션 또는 RPC)reviewed_by,reviewed_at컬럼 추가 검토 (현재 스키마 확인 필요)참고
/spsc에서 현재 스키마/세션 구조 확인 후 확정