Taehoon
ce1ed40561
- 통합 원격 접속 정보 UI 구현 (IP/MAC 및 계정 정보 통합) - 서버 측 스냅샷 비교 기반 자동 이력(Log) 생성 로직 도입 - 타임라인 UI 개선 (이벤트별 색상 뱃지 및 변동 사항 강조) - 자산 상세 필드 확장 (서비스 구분, 용도 등) - 테스트 데이터 생성기 및 이력 계획서 추가
61 lines
3.4 KiB
Markdown
61 lines
3.4 KiB
Markdown
# 자산 이력 누적 관리 시스템 (Cumulative Asset History System) 구현 계획
|
|
|
|
본 문서는 자산의 라이프사이클(조직, 사용자, 용도, 상태 변동)을 체계적으로 추적하고 누적 관리하기 위한 기술적 설계 및 단계별 구현 계획을 담고 있습니다.
|
|
|
|
## 1. 목적
|
|
- 자산 정보 수정 시 중요 변경 사항을 자동으로 감지하여 이력(Log)화
|
|
- 과거부터 현재까지의 변동 사항을 타임라인 형태로 시각화하여 자산 흐름 파악
|
|
- 데이터 정합성을 위해 서버 측에서 변경 전/후 스냅샷 비교 방식 채택
|
|
|
|
## 2. 관리 대상 이력 (Watch Fields)
|
|
다음 항목의 변경이 발생할 경우 이력을 자동 생성합니다.
|
|
1. **조직 변동**: `current_dept` (현 사용조직) ↔ `previous_dept` 업데이트 포함
|
|
2. **사용자 변동**: `user_current` (현 사용자) ↔ `previous_user` 업데이트 포함
|
|
3. **용도 변경**: `asset_type`, `current_role` (예: 개인PC -> 공용PC)
|
|
4. **상태 변경**: `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` 엔드포인트
|
|
- **동작 흐름**:
|
|
1. **Snapshot**: 인서트/업데이트 수행 전, 기존 DB의 데이터를 `SELECT`하여 메모리에 저장.
|
|
2. **Comparison**: 요청된 신규 데이터와 기존 데이터를 필드별로 대조.
|
|
3. **Auto-logging**: 변경점이 발견되면 `asset_history` 테이블에 즉시 인서트.
|
|
4. **Transaction**: 모든 로그 생성이 자산 저장과 하나의 트랜잭션으로 묶여야 함.
|
|
|
|
### 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) 확인.
|