feat: #73 학습 결과 입력 API 연결 (progress_record)

[wngjs8114]

관련 이슈

Closes #73

작업 내용

result_modal.html(FE2, #64)이 학습 결과 입력 UI는 갖췄지만 제출 로직(POST URL, 필드명)이 "BE 확정 후 연결"로 남아있던 부분을 연결한다.

• planner:progress_record (POST): DailyPlanItem의 학습 결과(완료/일부완료/못함)를 record_progress()로 저장
• 화면 이동 없이 모달에서 즉시 반영되는 기능이라 JSON API로 구현 (기존 원칙: 화면 이동은 Django Form, 모달 즉시 반영은 비동기 API)

API 계약

POST /planner/progress/<item_id>/
Request: {"status": "done"|"partial"|"not_done", "actual_minutes": number|null, "completion_percent": number|null}
Response 성공(200): {"item_id": int, "status": str, "actual_minutes": int, "completion_percent": int|null, "daily_plan_status": str}
Response 실패(400/404/409): {"message": str}

설계 결정 사항 (리뷰 과정에서 정리)

• 실패 응답도 JSON으로 통일: get_object_or_404() 대신 filter().first() + 수동 404 JSON 응답 사용. JS가 response.json()으로 파싱하는데 Django 기본 HTML 404가 오면 파싱 자체가 실패하기 때문
• 응답 형식은 저장소 기존 관례를 따름: isSuccess/code/message 감싸는 구조 대신, 기존 material_analysis_status처럼 평평한(flat) JSON
• 오늘 날짜 + 활성 시험기간만 수정 가능: daily_plan__date=timezone.localdate(), daily_plan__exam_period__status=ACTIVE 조건으로 제한 (URL 직접 호출로 미래/과거 계획을 임의 수정하는 것 방지)
• 타입 검증 강화: isinstance(x, int) + bool 별도 배제(파이썬에서 bool은 int의 서브클래스라 True/False가 실수로 통과하는 것 방지)로 문자열/실수/리스트 입력 시 500 대신 400 반환

이번 PR 범위 밖

• FE2의 rmSubmit 클릭 핸들러 JS 작성 (API 계약 전달 후 FE2 작업)
• today 화면에서 결과 입력 후 실시간 반영 (성공 시 window.location.reload() 권장 — summary/eod 통계까지 같이 갱신되어야 하므로)

테스트

• python manage.py test planner → 140개 통과 (기존 128 + 신규 12)
• 신규 테스트: done/partial/not_done 각각 정상 저장, 잘못된 completion_percent 거부, 문자열/실수 타입 입력 시 400(500 아님), 비-dict 본문 거부, 재제출 시 갱신(중복 생성 안 됨), 다른 사용자 접근 시 JSON 404, 오늘 아닌 계획 접근 차단, 마감된 계획 수정 거부(409), speed_factor 갱신 확인

[6ye0m]

실제 응답 스키마(flat JSON), 소유권+오늘날짜+ACTIVE 제한, bool/int 타입 검증, 마감된 계획 거부(409) 등 설계 방향은 다 좋습니다. 다만 머지 전에 정리할 게 있습니다.

1. progress_record()가 planner/views.py에 두 번 정의되어 있습니다 (블로킹)

bash
grep -n "^def progress_record" planner/views.py
367:def progress_record(request, item_id):
423:def progress_record(request, item_id):
367번째 줄: PR 설명에서 폐기했다고 하신 옛날 버전(isSuccess/code/message/result로 감싸는 구조)
423번째 줄: 실제로 쓰는 새 버전(flat JSON)

Python은 같은 이름으로 두 번 정의하면 나중 정의가 조용히 앞의 것을 덮어씁니다. 실제 동작(423번째 줄)은 의도하신 그대로 맞지만, 367~419번째 줄(53줄)이 아무도 호출 못 하는 죽은 코드로 남아있습니다.

같은 문제가 테스트 파일에도 있습니다

bash
grep -n "^class ProgressRecordViewTests" planner/tests.py
2220:class ProgressRecordViewTests(TestCase):
2325:class ProgressRecordViewTests(TestCase):

2220번째 줄 클래스(isSuccess 구조 검증하는 옛날 테스트 8개)는 모듈 네임스페이스에서 2325번째 줄 클래스에 덮어써져서, 파일엔 있지만 실제로 한 번도 실행되지 않습니다. python manage.py test planner.tests.ProgressRecordViewTests -v 2로 확인해보면 2325번째 줄 클래스의 12개만 실행됩니다.

부탁드리는 것

planner/views.py 365420번째 줄(옛날 progress_record 함수) 삭제
planner/tests.py 22202324번째 줄(옛날 ProgressRecordViewTests 클래스) 삭제
삭제 후 python manage.py test planner 재확인 (여전히 140개 통과해야 함)

2. record_progress()가 주는 값 중 일부가 응답에서 빠져 있습니다 (참고, 블로킹 아님)

python
result = record_progress(...)

result["daily_plan_item_status"], result["updated_speed_factor"]가 있는데

return JsonResponse({
"item_id": ..., "status": ..., "actual_minutes": ...,
"completion_percent": ..., "daily_plan_status": ...,
# daily_plan_item_status, updated_speed_factor 없음
})

PR 설명에 "실시간 반영은 범위 밖, 성공 시 reload 권장"이라고 명시하신 걸 보면 지금 당장은 프론트가 안 쓸 값들이라 문제는 아닙니다. 다만 나중에 새로고침 없는 실시간 반영으로 갈 때 다시 추가해야 할 것 같아, 미리 알아두시면 좋을 것 같아 남깁니다. 지금 같이 넣어두셔도 무방해 보입니다.

1번만 정리되면 나머지는 실제로 코드 받아서 로직(트랜잭션, select_for_update, 예외 매핑)까지 확인했고 문제없습니다. 정리 부탁드립니다!

[wngjs8114]

확인 감사합니다. 말씀해주신 중복 정의 문제 확인했습니다.

• planner/views.py의 구버전 progress_record() 삭제
• planner/tests.py의 구버전 ProgressRecordViewTests 삭제
• 최종 함수와 테스트 클래스가 각각 하나만 남도록 정리

삭제된 테스트 클래스는 동일한 클래스명으로 덮어써져 기존에도 실행되지 않던 코드라, 정리 후에도 python manage.py test planner 기준 140개 전체 통과하는 것 확인했습니다.

daily_plan_item_status, updated_speed_factor는 현재 FE 연결에서 성공 후 전체 새로고침을 사용할 예정이라 이번 API 응답에는 추가하지 않고, 추후 새로고침 없는 실시간 반영 시 검토하겠습니다.