🎯 핵심 개선사항:
- 수신함에서 진행중/완료로 상태 변경시 project_sequence_no 자동 할당
- 프로젝트별로 1부터 시작하는 깔끔한 순번 체계
🔧 백엔드 수정:
- inbox.py: update_issue_status에 자동 할당 로직 추가
- generate_project_sequence_no() DB 함수 활용
- 진행중/완료 상태 변경시에만 실행
📁 DB 마이그레이션:
- 017_fix_project_sequence_no.sql 생성
- 기존 데이터 보정 (누락된 순번 0개 확인)
- migration_log 테이블 구조에 맞게 로그 기록
📋 문서화:
- DB_CHANGES_LOG.md 생성 및 업데이트
- 배포 가이드, 검증 방법, 주의사항 명시
- Docker 환경 기준 실행 방법 제공
✅ 실행 완료 상태:
- 마이그레이션 성공 (2025-10-26 11:15:44+09:00)
- 백엔드 서비스 재시작 완료
- 모든 검증 항목 통과
Expected Result:
🎯 현황판에서 프로젝트별 No.1, No.2, No.3... 표시
🎯 6개월 후에도 각 프로젝트 내에서 작은 번호 유지
🎯 전체 통합 번호 대신 프로젝트별 깔끔한 순번 체계
🗑️ Remove Unnecessary Field:
- 처리 메모 (statusNotes) 필드 제거
- 완료됨 선택 시 해결방안 필드가 있어 중복 불필요
- 진행 중 선택 시 별도 메모 불필요
🎨 UI Simplification:
- 모달 UI에서 처리 메모 텍스트 영역 제거
- 더 깔끔하고 집중된 사용자 인터페이스
- 필수 정보에만 집중할 수 있도록 개선
🔧 Backend Cleanup:
- IssueStatusUpdateRequest에서 notes 필드 제거
- API 엔드포인트에서 notes 처리 로직 제거
- 불필요한 detail_notes 업데이트 로직 제거
💡 User Experience:
- 더 간단하고 직관적인 상태 변경 프로세스
- 완료 시에는 해결방안으로 충분한 정보 제공
- 진행 중 시에는 바로 처리 가능
Expected Result:
✅ 처리 메모 필드 완전 제거
✅ 더 간결한 상태 결정 모달
✅ 중복 기능 제거로 사용자 혼란 방지
✅ 핵심 기능에 집중된 워크플로우
🔄 Status Modal Improvements:
- 진행 중 / 완료됨 2개 옵션으로 단순화
- 진행 중 선택 시 바로 관리함으로 이동
- 완료됨 선택 시 추가 정보 입력 섹션 표시
📝 Completion Information Fields:
- 완료 사진 업로드 (1장, 선택사항)
- 해결방안 입력 (어떻게 해결했는지)
- 해결한 부서 선택 (담당부서)
- 해결한 사람 입력 (담당자)
- 모든 필드는 선택사항으로 관리함에서 나중에 입력 가능
🎨 Frontend Implementation:
- completionSection으로 통합된 완료 관련 UI
- 상태 선택에 따른 동적 섹션 표시/숨김
- 부서 선택 드롭다운 (생산, 품질, 구매, 설계, 영업)
- 직관적인 아이콘과 색상으로 필드 구분
- 사용자 안내 메시지로 UX 개선
🔧 Backend API Updates:
- IssueStatusUpdateRequest에 solution, responsible_department, responsible_person 필드 추가
- update_issue_status API에서 완료 상태 시 추가 필드 처리
- 해결방안, 담당부서, 담당자 정보 자동 저장
🚀 User Experience:
- 진행 중: 클릭 한 번으로 바로 관리함 이동
- 완료됨: 필요한 정보를 한 번에 입력하고 완료 처리
- 선택사항 필드로 유연한 워크플로우 지원
- 관리함에서 나중에 추가/수정 가능한 구조
💡 Workflow Optimization:
- 수신함에서 완료 처리 시 필요한 정보를 미리 입력
- 관리함 작업량 감소 및 효율성 향상
- 완료 확인일 자동 기록으로 추적 개선
Expected Result:
✅ 진행 중 선택 시 바로 관리함 이동
✅ 완료됨 선택 시 해결방안, 담당부서, 담당자 입력 가능
✅ 완료 사진과 함께 종합적인 완료 정보 수집
✅ 선택사항 필드로 유연한 사용 가능
✅ 관리함에서 추가 편집 가능한 구조
📸 Completion Photo Upload:
- 수신함에서 '완료됨' 상태 선택 시 완료 사진 업로드 기능 추가 (1장 제한)
- Base64 인코딩으로 사진 업로드 및 미리보기 기능
- 완료 상태 변경 시 actual_completion_date 자동 설정
🗄️ Final Issue DB Structure:
- 최종 부적합 사항을 위한 포괄적인 DB 스키마 설계 및 구현
- 프로젝트별 순번 (project_sequence_no) 자동 생성 시스템
📋 New Database Fields:
- completion_photo_path: 완료 사진 경로
- solution: 해결방안 (관리함에서 입력)
- responsible_department: 담당부서 (department_type ENUM)
- responsible_person: 담당자 (VARCHAR 100)
- expected_completion_date: 조치 예상일 (DATE)
- actual_completion_date: 완료 확인일 (DATE, 자동 설정)
- cause_department: 원인부서 (department_type ENUM)
- management_comment: ISSUE에 대한 의견 (TEXT)
- final_description: 최종 내용 (수정본 또는 원본)
- final_category: 최종 카테고리 (수정본 또는 원본)
🔧 Backend Implementation:
- Issue 모델에 11개 새 필드 추가
- IssueStatusUpdateRequest에 completion_photo 필드 추가
- ManagementUpdateRequest 스키마 신규 생성
- update_issue_status API에 완료 사진 처리 로직 추가
- generate_project_sequence_no() 함수로 프로젝트별 순번 자동 생성
🎨 Frontend Implementation:
- 상태 결정 모달에 완료 사진 업로드 섹션 추가
- 완료 상태 선택 시에만 사진 업로드 UI 표시
- 파일 크기 제한 (5MB), 이미지 파일 검증
- 사진 미리보기 및 Base64 변환 처리
- 완료 사진 없이 완료 처리 시 확인 다이얼로그
🚀 User Experience:
- 직관적인 완료 사진 업로드 워크플로우
- 실시간 사진 미리보기로 업로드 확인 가능
- 완료 처리 시 자동으로 완료 확인일 기록
- 프로젝트별 순번으로 체계적인 이슈 관리
🔍 Database Migration:
- 016_add_management_fields.sql 마이그레이션 성공적으로 실행
- 멱등성 보장 및 기존 데이터 보존
- 인덱스 최적화 (project_sequence, responsible_department, expected_completion)
- 기존 이슈들의 final_description/final_category 자동 초기화
Expected Result:
✅ 수신함에서 완료 상태 선택 시 완료 사진 업로드 가능
✅ 완료 처리 시 완료 확인일 자동 기록
✅ 프로젝트별 순번으로 체계적인 이슈 번호 관리
✅ 관리함에서 사용할 모든 필드 준비 완료
✅ 최종 부적합 사항 리포트 생성을 위한 DB 구조 완성
🔐 Permission System Consistency:
- 수신함/관리함/폐기함 권한이 있는 사용자는 모든 이슈 조회/처리 가능
- 기존: 조회는 관리자만, 처리는 권한 사용자 → 일관성 부족
- 개선: 조회와 처리 모두 동일한 권한 체계 적용
📋 Issues API Updates:
- GET /api/issues/admin/all: get_current_admin → get_current_user + 권한 체크
- 이슈 관리 관련 페이지 권한 확인 (issues_manage, issues_inbox, issues_management, issues_archive)
- 관리자이거나 해당 권한이 있는 사용자만 접근 가능
🔄 Inbox API Updates:
- 모든 수신함 워크플로우 API: get_current_admin → get_current_user + 페이지 권한 체크
- dispose_issue: 수신함 권한 확인 추가
- review_issue: 수신함 권한 확인 추가
- update_issue_status: 수신함 권한 확인 추가
🎯 Permission Logic:
- 사용자 관리 (auth.py): 관리자 전용 유지 (보안상 중요)
- 이슈 관리: 권한 부여된 사용자 모두 접근 가능
- 수신함 워크플로우: 권한 부여된 사용자 모두 접근 가능
🔧 Technical Implementation:
- check_page_access() 함수로 페이지별 권한 체크
- 관리자는 자동으로 모든 권한 보유
- 일반 사용자는 개별 페이지 권한 확인
🚀 User Experience:
- 권한이 있는 일반 사용자도 수신함에서 이슈 처리 가능
- 일관된 권한 체계로 사용자 혼란 방지
- 관리자와 권한 사용자 동일한 기능 제공
Expected Result:
✅ 수신함 권한이 있는 일반 사용자도 이슈 폐기/검토/상태변경 가능
✅ 이슈 관리 권한이 있는 사용자도 모든 이슈 조회 가능
✅ 권한 시스템 전체적으로 일관성 있게 통일
✅ 사용자 관리만 관리자 전용으로 보안 유지
🔄 Duplicate Tracking System:
- 중복 신고 시 원본 이슈에 신고자 정보 자동 추가
- 신고 인지도 및 대응 속도 분석을 위한 데이터 수집
- 뒷북치는 신고자 파악 및 집계 기능
📊 Database Schema Updates:
- duplicate_of_issue_id: 중복 대상 이슈 ID (FK)
- duplicate_reporters: 중복 신고자 목록 (JSONB 배열)
- 015_add_duplicate_tracking.sql 마이그레이션 실행
- GIN 인덱스로 JSONB 검색 성능 최적화
🔧 Backend Enhancements:
- 중복 폐기 시 대상 이슈에 신고자 정보 자동 추가
- 신고자 중복 체크 로직 (동일 사용자 재추가 방지)
- /api/inbox/management-issues API 추가 (중복 선택용)
- 프로젝트별 관리함 이슈 목록 조회 지원
🎨 Frontend UI Improvements:
- 중복 선택 시 관리함 이슈 목록 표시
- 프로젝트별 필터링된 이슈 목록 제공
- 간단한 이슈 정보 표시 (제목, 카테고리, 신고자, 중복 건수)
- 직관적인 선택 UI (클릭으로 선택, 시각적 피드백)
📋 Duplicate Selection Process:
1. 폐기 사유로 '중복' 선택
2. 동일 프로젝트의 관리함 이슈 목록 자동 로드
3. 중복 대상 이슈 선택 (필수)
4. 확인 시 신고자 정보가 원본 이슈에 추가
💾 Data Structure:
- duplicate_reporters: [
{
user_id: 123,
username: 'reporter1',
full_name: '신고자1',
report_date: '2024-10-25T14:30:00',
added_at: '2024-10-25T15:00:00'
}
]
🔍 Analytics Features:
- 중복 신고 건수 표시
- 신고자별 신고 시점 추적
- 원본 이슈 대비 지연 신고 분석 가능
- 부서별/사용자별 인지도 분석 데이터 제공
🚀 User Experience:
- 중복 처리 시 명확한 안내 메시지
- 관리함 이슈 목록 실시간 로드
- 선택 필수 검증 (중복 대상 미선택 시 경고)
- 처리 완료 후 자동 목록 새로고침
Expected Result:
✅ 중복 신고 시 신고자 정보 자동 추적
✅ 신고 인지도 및 대응 속도 분석 데이터 수집
✅ 직관적인 중복 대상 선택 UI
✅ 부서별/개인별 신고 패턴 분석 기반 마련
🔧 Backend Fix:
- 수신함 라우터 prefix 수정: /inbox → /api/inbox
- 다른 API들과 일관성 있는 경로 구조 적용
- FastAPI 라우터 등록 정상화
🎨 Frontend Fix:
- 공통 헤더 초기화 로그 추가
- currentUser undefined 문제 디버깅 준비
- API 연동 상태 확인 로그 강화
🔍 Issue Analysis:
- 수신함 API 404 에러 → 경로 문제로 확인
- 공통 헤더 안보임 → currentUser 초기화 문제로 추정
- 백엔드 재시작으로 API 정상화 확인
Result:
✅ 수신함 API 엔드포인트 정상화 (/api/inbox/)
✅ 인증 필요 응답 확인 (API 작동 중)
🔄 공통 헤더 디버깅 로그 추가 (다음 테스트 대기)
🔧 Models & Schemas:
- 새로운 ENUM 클래스 추가:
* ReviewStatus: pending_review, in_progress, completed, disposed
* DisposalReasonType: duplicate, invalid_report, not_applicable, spam, custom
- Issue 모델 확장 (8개 새 필드):
* review_status: 수신함 워크플로우 상태 (기본값: pending_review)
* disposal_reason: 폐기 사유 ENUM
* custom_disposal_reason: 사용자 정의 폐기 사유
* disposed_at: 폐기 처리 시간
* reviewed_by_id: 검토자 FK (users.id)
* reviewed_at: 검토 완료 시간
* original_data: 원본 데이터 보존 (JSONB)
* modification_log: 수정 이력 추적 (JSONB)
- User 모델 관계 수정:
* issues: 신고한 부적합 (foreign_keys 명시)
* reviewed_issues: 검토한 부적합 (새로 추가)
🎯 Pydantic Schemas:
- 기존 Issue 스키마에 워크플로우 필드 추가
- 수신함 전용 스키마들:
* IssueDisposalRequest: 폐기 요청
* IssueReviewRequest: 검토/수정 요청
* IssueStatusUpdateRequest: 상태 변경 요청
* InboxIssue: 수신함용 간소화 모델
* ModificationLogEntry: 수정 이력 항목
🚀 API Endpoints (/api/inbox):
- GET /: 수신함 부적합 목록 (프로젝트 필터링, 페이징)
- POST /{id}/dispose: 부적합 폐기 처리 (관리자 전용)
- POST /{id}/review: 부적합 검토/수정 (관리자 전용)
- POST /{id}/status: 최종 상태 결정 (관리자 전용)
- GET /{id}/history: 수정 이력 조회
- GET /statistics: 수신함 통계
🔒 Security & Validation:
- 관리자 전용 액션 (폐기, 검토, 상태변경)
- 사용자 정의 폐기 사유 검증
- 프로젝트 존재 여부 확인
- 상태 변경 로직 검증
📊 Data Preservation:
- 원본 데이터 자동 보존 (최초 1회)
- 모든 수정사항 이력 추적
- 검토자 및 시간 기록
- 폐기 사유 및 시간 기록
🎯 Workflow Logic:
업로드(pending_review) → 수신함 검토 → [폐기→폐기함] or [승인→관리함]
- 폐기: disposed 상태, 폐기함으로
- 승인: in_progress/completed 상태, 관리함으로
- 모든 변경사항 추적 및 보존
Result:
✅ 수신함 워크플로우 백엔드 100% 완성
✅ DB 스키마와 완벽 동기화
✅ 데이터 무결성 및 추적성 보장
✅ RESTful API 설계 준수
✅ 관리자 권한 기반 보안 적용
