증상: 사용자가 iPhone HEIC 사진을 관리함에서 업로드하면 400 Bad Request.
로그:
⚠️ pillow_heif 직접 처리 실패: Metadata not correctly assigned to image
❌ HEIF 처리도 실패: cannot identify image file
원인: pillow_heif 가 특정 iPhone 이 생성한 HEIC 의 메타데이터를 처리 못함.
libheif 를 직접 사용하는 ImageMagick 이 더 범용적이라 system2-report/imageUploadService.js
와 동일한 패턴으로 fallback 추가.
변경:
- Dockerfile: imagemagick + libheif1 apt-get 추가 + HEIC policy.xml 해제
- file_service.py: pillow_heif/PIL 실패 시 subprocess 로 magick/convert 호출해서
임시 파일로 JPEG 변환 후 다시 PIL 로 open
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
근본 원인: 2026-04-01 보안 패치(f09c86e)에서 system3-api Dockerfile에
USER appuser 추가했으나, named volume(tkqc-package_uploads)이 root 소유로
남아있어 appuser(999)가 /app/uploads 에 쓰기 실패. 하지만 file_service.py
가 except → return None 으로 silent failure 처리해서 system2는 200 OK 로
인식. 결과: 4/1 이후 qc_issues.id=185~191 사진이 전부 photo_path=NULL.
조치:
1. system3 Dockerfile: entrypoint.sh 추가 → 시작 시 chown 후 gosu appuser 강등
(named volume 이 restart 후에도 root로 돌아가는 문제 영구 해결)
2. file_service.py: save_base64_image 실패 시 RuntimeError raise (silent 금지)
3. system2 workIssueController: sendToMProject 실패/예외 시 system 알림 발송
4. 관리함 (desktop + mobile): 이슈 상세/편집 모달에 원본 사진 보충 UI 추가
- 빈 슬롯(photo_path{N}=NULL)에만 자동 채움, 기존 사진 유지
- ManagementUpdateRequest 스키마에 photo/photo2~5 필드 추가
- update_issue_management 엔드포인트에 사진 저장 루프 추가
런타임 chown 으로 immediate data loss 는 이미 차단됨 (09:28 KST).
이 커밋은 재발 방지 + 데이터 복구 UI 제공.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TK-FB(공장관리+신고)와 M-Project(부적합관리)를 3개 독립 시스템으로
분리하기 위한 전체 코드 구조 작성.
- SSO 인증 서비스 (bcrypt + pbkdf2 이중 해시 지원)
- System 1: 공장관리 (TK-FB 기반, 신고 코드 제거)
- System 2: 신고 (TK-FB에서 workIssue 코드 추출)
- System 3: 부적합관리 (M-Project 기반)
- Gateway 포털 (path-based 라우팅)
- 통합 docker-compose.yml 및 배포 스크립트
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
