Taehoon
ce1ed40561
- 통합 원격 접속 정보 UI 구현 (IP/MAC 및 계정 정보 통합) - 서버 측 스냅샷 비교 기반 자동 이력(Log) 생성 로직 도입 - 타임라인 UI 개선 (이벤트별 색상 뱃지 및 변동 사항 강조) - 자산 상세 필드 확장 (서비스 구분, 용도 등) - 테스트 데이터 생성기 및 이력 계획서 추가
3.4 KiB
3.4 KiB
자산 이력 누적 관리 시스템 (Cumulative Asset History System) 구현 계획
본 문서는 자산의 라이프사이클(조직, 사용자, 용도, 상태 변동)을 체계적으로 추적하고 누적 관리하기 위한 기술적 설계 및 단계별 구현 계획을 담고 있습니다.
1. 목적
- 자산 정보 수정 시 중요 변경 사항을 자동으로 감지하여 이력(Log)화
- 과거부터 현재까지의 변동 사항을 타임라인 형태로 시각화하여 자산 흐름 파악
- 데이터 정합성을 위해 서버 측에서 변경 전/후 스냅샷 비교 방식 채택
2. 관리 대상 이력 (Watch Fields)
다음 항목의 변경이 발생할 경우 이력을 자동 생성합니다.
- 조직 변동:
current_dept(현 사용조직) ↔previous_dept업데이트 포함 - 사용자 변동:
user_current(현 사용자) ↔previous_user업데이트 포함 - 용도 변경:
asset_type,current_role(예: 개인PC -> 공용PC) - 상태 변경:
hw_status(예: 운영 -> 수리, 재고 -> 폐기 등)
3. 기술 설계 (Technical Design)
A. 데이터베이스 (DB)
- 대상 테이블:
asset_history - 컬럼 구조 활용 및 보완:
asset_id: 대상 자산 식별자event_type: 변경 유형 (DEPT_CHANGE, USER_CHANGE, ROLE_CHANGE, STATUS_CHANGE)details: "상태 변경: 운영 -> 수리" 와 같이 읽기 쉬운 문자열 저장cost: 관련 비용 발생 시 기록 (수리비 등)log_user: 변경을 수행한 작업자log_date: 변경 발생 일시
B. 백엔드 (Server-side Logic)
- 위치:
server.js의POST /api/asset/:category/save엔드포인트 - 동작 흐름:
- Snapshot: 인서트/업데이트 수행 전, 기존 DB의 데이터를
SELECT하여 메모리에 저장. - Comparison: 요청된 신규 데이터와 기존 데이터를 필드별로 대조.
- Auto-logging: 변경점이 발견되면
asset_history테이블에 즉시 인서트. - Transaction: 모든 로그 생성이 자산 저장과 하나의 트랜잭션으로 묶여야 함.
- Snapshot: 인서트/업데이트 수행 전, 기존 DB의 데이터를
C. 프론트엔드 (UI/UX)
- 위치:
HWModal.ts우측modal-history-area - 개선 사항:
renderHistory()함수를 고도화하여 이벤트 타입별 아이콘/컬러 적용.- "이전 값 ➔ 이후 값" 형태의 직관적인 레이아웃 도입.
- 스크롤을 통한 무제한 누적 이력 조회 지원.
4. 단계별 구현 로직
1단계: 서버 로직 고도화
server.js에 비교 함수(compareAndLog) 구현.- 각 자산 카테고리별 저장 로직에 비교 로직 삽입.
2단계: DB 데이터 마이그레이션 (필요시)
- 기존 자산의
current_dept등을previous_dept로 밀어내는 로직 점검.
3단계: UI 타임라인 렌더링 개선
modal.css에 이력 전용 스타일(이벤트 뱃지 등) 추가.HWModal.ts에서 최신 로그를 실시간으로 다시 불러오는 로직 확인.
5. 검증 계획
- 자동 감지 테스트: 상태 변경 후 저장 시 우측 이력에 즉시 한 줄이 추가되는지 확인.
- 다중 변경 테스트: 조직과 사용자를 동시에 변경했을 때 두 개의 로그가 생성되는지 확인.
- 데이터 무결성: 수정을 취소하거나 저장 실패 시 로그가 남지 않는지(Transaction) 확인.