초록 접수 시스템 상태값 설계 기준 및 권한 제어 가이드

초록 접수부터 최종 게재까지: 전체 프로세스 상태값 정의 및 흐름도 설계

상태 전이 흐름도, 어디서 꼬이는가

초록 접수 운영의 병목은 흔히 '심사위원이 수정 요청한 초록이 운영자에게 안 보이는 상황'에서 발생합니다. 저자가 초록을 다시 제출해도, 시스템 상태값이 '심사 중'에 머물러 있으면 운영자는 최종 승인을 누를 수 없습니다. 따라서 상태값 설계의 기준은 단순히 단계를 나누는 것이 아니라 '데이터가 다음 담당자에게 정확히 제어권을 넘겨주는가'여야 합니다.

저자·심사위원·운영자 역할별 DB 상태값 변경 로직 및 복수 심사 병합 처리

저자가 바꾸는 값, 심사위원이 바꾸는 값

저자가 임시 저장에서 최종 제출로 넘기는 순간, 해당 초록은 수정 불가 상태로 잠겨야 합니다. 반대로 반려 후 재투고가 열리면 다시 편집 권한이 풀려야 하죠. 이 전환 지점을 명확히 해야 심사 중인 데이터가 꼬이지 않습니다. ### 복수 심사에서 중간 상태값을 다루는 법

• 부분 승인/반려: 심사위원 A는 승인, B는 수정 요청일 때, 초록을 즉시 확정하지 말고 대기 상태로 둡니다.

상태값별 UI 접근 권한·버튼 노출 제어 및 운영자 예외 통제 설계

예외 통제가 없으면 상태값은 '장식'이다

기한 연장, 강제 마감, 반려 후 재수정 요청은 초록 접수 현장에서 가장 잦은 예외 상황이다. 저자가 마감 직전에 제출을 누르지 못했거나, 심사위원이 반려 사유를 남겼는데 시스템이 잠겨버리면 사무국 창 앞에서 문의 전화가 쏟아진다. 운영자 대시보드는 이 순간에 상태값을 직접 바꾸고, 저자 화면의 '수정·제출' 버튼과 심사위원 화면의 '평가' 버튼을 다시 열어주는 통제 권한을 가져야 한다.

개발 전 필수 점검 요약 및 ERD 설계 체크리스트 (비오케이솔루션)

초록 접수는 단순한 '입력 폼'이 아니라, 결제와 출결·전자초록집으로 이어지는 운영 데이터의 출발점입니다. 설계를 시작하기 전, 핵심 항목부터 점검해야 합니다.

• 상태값: 접수·심사·게재 확정까지의 단계가 명확히 구분되는가?
• 권한: 일반 회원, 심사위원, 관리자가 각기 다른 화면과 데이터에만 접근할 수 있는가?
• 예외 통제: 기한 마감 후 임의 접수나 결제 취소 시, 데이터가 끊기지 않는가?

실행 전 점검표