M-Project/DB_CHANGE_LOG.md

# 데이터베이스 변경 로그

이 문서는 M-Project 데이터베이스의 모든 변경사항을 추적하고 기록합니다.

---

## 변경 로그 템플릿

새로운 변경사항이 있을 때마다 아래 템플릿을 사용하여 기록해주세요.

```markdown
## [변경 ID] - [변경 제목] (YYYY-MM-DD)

### 변경 유형
- [ ] 새 테이블 추가
- [ ] 기존 테이블 수정
- [ ] 컬럼 추가/삭제/수정
- [ ] 인덱스 추가/삭제
- [ ] 제약조건 추가/삭제
- [ ] ENUM 타입 수정
- [ ] 데이터 마이그레이션
- [ ] 성능 최적화
- [ ] 기타: ___________

### 변경 내용
**요약:** [변경사항을 한 줄로 요약]

**상세 설명:**
- 변경 이유:
- 영향받는 테이블:
- 새로 추가된 컬럼/테이블:
- 삭제된 컬럼/테이블:

### 마이그레이션 정보
- **파일명:** `XXX_description.sql`
- **실행 순서:** [이전 마이그레이션 이후 순서]
- **롤백 가능 여부:** [Yes/No]
- **데이터 손실 위험:** [High/Medium/Low/None]

### SQL 스크립트
```sql
-- 마이그레이션 SQL 코드
```

### 테스트 체크리스트
- [ ] 로컬 환경에서 테스트 완료
- [ ] 기존 데이터 호환성 확인
- [ ] 애플리케이션 코드 업데이트 완료
- [ ] API 테스트 완료
- [ ] 성능 영향 확인

### 영향도 분석
**애플리케이션 영향:**
- 백엔드 API: [영향 있음/없음]
- 프론트엔드: [영향 있음/없음]
- 기존 데이터: [영향 있음/없음]

**호환성:**
- 이전 버전과의 호환성: [유지/중단]
- 필요한 코드 변경사항: [있음/없음]

### 담당자
- **개발자:** [이름]
- **검토자:** [이름]
- **승인자:** [이름]
- **적용일:** YYYY-MM-DD

---
```

---

## 변경 히스토리

### [012] - 권한 시스템 단순화 및 페이지별 접근 권한 구현 (2025-10-25)

#### 변경 유형
- [x] 테이블 구조 변경
- [x] ENUM 타입 수정
- [x] 기존 테이블 삭제
- [x] 새 테이블 추가

#### 변경 내용
**요약:** 복잡한 4단계 권한을 admin/user 구조로 단순화하고 페이지별 접근 권한 시스템 도입

**상세 설명:**
- 변경 이유: 사용자 요청에 따른 권한 시스템 단순화
- 삭제된 테이블: user_permissions (복잡한 권한 테이블)
- 새로 추가된 테이블: user_page_permissions (페이지별 권한)
- 역할 단순화: super_admin, manager → admin으로 통합
- 새로운 권한 방식: 페이지별 접근 허용/차단

#### 마이그레이션 정보
- **파일명:** `012_simplify_permissions.sql`
- **실행 순서:** 011 이후
- **롤백 가능 여부:** Partial (기존 복잡한 권한 데이터 손실)
- **데이터 손실 위험:** Medium (기존 권한 설정 초기화)

#### SQL 스크립트
```sql
-- 기존 복잡한 권한 테이블 삭제
DROP TABLE IF EXISTS user_permissions CASCADE;

-- 페이지별 접근 권한 테이블 생성
CREATE TABLE user_page_permissions (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    page_name VARCHAR(50) NOT NULL,
    can_access BOOLEAN DEFAULT FALSE,
    granted_by_id INTEGER REFERENCES users(id),
    granted_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    notes TEXT,
    UNIQUE(user_id, page_name)
);

-- 페이지 접근 권한 체크 함수
CREATE OR REPLACE FUNCTION check_page_access(p_user_id INTEGER, p_page_name VARCHAR) RETURNS BOOLEAN;

-- 기존 복잡한 역할을 admin으로 통합
UPDATE users SET role = 'admin' WHERE role IN ('super_admin', 'manager');
```

#### 새로운 페이지 권한 시스템
**기본 페이지 목록:**
- `issues_create`: 부적합 등록 (기본: 허용)
- `issues_view`: 부적합 조회 (기본: 허용)  
- `issues_manage`: 부적합 관리 (기본: 차단)
- `projects_manage`: 프로젝트 관리 (기본: 차단)
- `daily_work`: 일일 공수 (기본: 차단)
- `reports`: 보고서 (기본: 차단)

**권한 규칙:**
- **admin**: 모든 페이지 접근 가능
- **user**: 개별 페이지 권한에 따라 접근
- 권한 미설정 시: 기본값 적용

#### 관리자 인터페이스 개선
**새로운 기능:**
1. **페이지 권한 관리 섹션** (`admin.html`)
   - 사용자별 페이지 접근 권한 설정
   - 체크박스 방식의 직관적 인터페이스
   - 실시간 권한 저장 기능

2. **단순화된 권한 JavaScript** (`permissions.js`)
   - `PagePermissionManager` 클래스
   - `canAccessPage()` 함수
   - 페이지별 UI 제어 기능

#### 테스트 체크리스트
- [x] 로컬 환경에서 테스트 완료
- [x] 데이터베이스 마이그레이션 성공
- [x] 기존 admin 사용자 권한 유지
- [x] 새로운 권한 관리 UI 구현
- [ ] 페이지별 접근 제어 테스트
- [ ] API 엔드포인트 구현

#### 영향도 분석
**애플리케이션 영향:**
- 백엔드 API: 페이지 권한 API 엔드포인트 추가 필요
- 프론트엔드: 권한 체크 로직 단순화
- 기존 데이터: admin 사용자는 모든 권한 유지

**호환성:**
- 이전 버전과의 호환성: 부분적 유지
- 필요한 코드 변경사항: 권한 체크 함수 변경

#### 사용 방법
1. **관리자 권한 설정**
   ```
   http://localhost:16080/admin.html
   → 페이지 접근 권한 관리 섹션
   → 사용자 선택 → 페이지별 체크박스 설정
   ```

2. **권한 체크 (JavaScript)**
   ```javascript
   // 기존
   if (hasPermission('issues.edit')) { ... }
   
   // 신규
   if (canAccessPage('issues_manage')) { ... }
   ```

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [011] - 권한 시스템 개선 및 애플리케이션 리팩토링 (2025-10-25)

#### 변경 유형
- [x] 새 테이블 추가
- [x] ENUM 타입 수정
- [x] 제약조건 추가/삭제
- [x] 기타: 대규모 리팩토링

#### 변경 내용
**요약:** 세분화된 권한 시스템 도입 및 통합 SPA 애플리케이션으로 리팩토링

**상세 설명:**
- 변경 이유: 단순한 admin/user 구조의 한계, 코드 중복 및 유지보수성 문제 해결
- 영향받는 테이블: users (role 확장), user_permissions (신규)
- 새로 추가된 테이블: user_permissions
- 새로 추가된 역할: super_admin, manager
- 새로 추가된 파일: app.html, permissions.js, app.js

#### 마이그레이션 정보
- **파일명:** `011_add_permission_system.sql`
- **실행 순서:** 010 이후
- **롤백 가능 여부:** Partial (새 역할은 롤백 불가)
- **데이터 손실 위험:** Low

#### SQL 스크립트
```sql
ALTER TYPE userrole ADD VALUE 'super_admin';
ALTER TYPE userrole ADD VALUE 'manager';

CREATE TABLE user_permissions (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    permission VARCHAR(50) NOT NULL,
    granted BOOLEAN DEFAULT TRUE,
    granted_by_id INTEGER REFERENCES users(id),
    granted_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    revoked_at TIMESTAMP WITH TIME ZONE,
    notes TEXT,
    UNIQUE(user_id, permission)
);

-- 권한 체크 함수들 생성
CREATE OR REPLACE FUNCTION check_user_permission(p_user_id INTEGER, p_permission VARCHAR) RETURNS BOOLEAN;
-- ... 기타 함수들
```

#### 새로운 기능
1. **세분화된 권한 시스템**
   - 4단계 사용자 역할 (super_admin, admin, manager, user)
   - 개별 권한 부여/취소 기능
   - 권한 기반 UI 동적 제어

2. **통합 SPA 애플리케이션**
   - 단일 페이지 애플리케이션 (app.html)
   - 모듈 기반 아키텍처
   - 동적 라우팅 시스템

3. **모듈화된 코드 구조**
   - 핵심 시스템 모듈 (core/)
   - 기능별 모듈 분리 (modules/)
   - 재사용 가능한 컴포넌트

#### 테스트 체크리스트
- [x] 로컬 환경에서 테스트 완료
- [x] 기존 데이터 호환성 확인
- [x] 데이터베이스 마이그레이션 성공
- [ ] 새 권한 시스템 테스트
- [ ] 통합 앱 기능 테스트

#### 영향도 분석
**애플리케이션 영향:**
- 백엔드 API: 권한 체크 로직 업데이트 필요
- 프론트엔드: 완전히 새로운 구조로 변경
- 기존 데이터: 호환성 유지 (기존 admin → super_admin 자동 변경)

**호환성:**
- 이전 버전과의 호환성: 부분적 유지 (API 호환)
- 필요한 코드 변경사항: 대규모 변경

#### 새로운 파일 목록
**프론트엔드:**
- `app.html` - 통합 메인 애플리케이션
- `static/js/core/permissions.js` - 권한 관리 시스템
- `static/js/app.js` - 메인 애플리케이션 로직

**문서:**
- `REFACTORING_PLAN.md` - 리팩토링 계획서
- `MODULE_ARCHITECTURE.md` - 모듈 아키텍처 문서

#### 권한 매트릭스
| 기능 | super_admin | admin | manager | user |
|------|-------------|--------|---------|------|
| 부적합 등록 | ✅ | ✅ | ✅ | ✅ |
| 부적합 조회 | ✅ | ✅ | ✅ | ✅ |
| 부적합 수정 | ✅ | ✅ | ✅ | ❌ |
| 부적합 삭제 | ✅ | ✅ | ❌ | ❌ |
| 프로젝트 생성 | ✅ | ✅ | ❌ | ❌ |
| 프로젝트 수정 | ✅ | ✅ | ❌ | ❌ |
| 프로젝트 삭제 | ✅ | ❌ | ❌ | ❌ |
| 사용자 관리 | ✅ | ❌ | ❌ | ❌ |
| 권한 관리 | ✅ | ❌ | ❌ | ❌ |

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [010] - 부적합 카테고리에 'etc' 값 추가 (2025-10-25)

#### 변경 유형
- [x] ENUM 타입 수정

#### 변경 내용
**요약:** issuecategory ENUM 타입에 'etc' (기타) 값 추가하여 백엔드 코드와 DB 불일치 해결

**상세 설명:**
- 변경 이유: 백엔드 models.py에는 'etc' 값이 있지만 DB enum에는 없어서 INSERT 시 에러 발생
- 영향받는 테이블: issues (category 컬럼)
- 새로 추가된 값: issuecategory.etc
- 삭제된 컬럼/테이블: 없음

#### 마이그레이션 정보
- **파일명:** `010_add_etc_category.sql`
- **실행 순서:** 009 이후
- **롤백 가능 여부:** No (PostgreSQL enum 값 삭제 불가)
- **데이터 손실 위험:** None

#### SQL 스크립트
```sql
ALTER TYPE issuecategory ADD VALUE 'etc';
```

#### 테스트 체크리스트
- [x] 로컬 환경에서 테스트 완료
- [x] 기존 데이터 호환성 확인
- [x] 애플리케이션 코드 업데이트 완료 (이미 존재함)
- [x] API 테스트 완료
- [x] 성능 영향 확인

#### 영향도 분석
**애플리케이션 영향:**
- 백엔드 API: 영향 없음 (이미 코드에 존재)
- 프론트엔드: 영향 없음 (이미 UI에 존재)
- 기존 데이터: 영향 없음

**호환성:**
- 이전 버전과의 호환성: 유지
- 필요한 코드 변경사항: 없음

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [009] - 프로젝트별 일일공수 테이블 추가 (2025-10-25)

#### 변경 유형
- [x] 새 테이블 추가
- [x] 데이터 마이그레이션

#### 변경 내용
**요약:** 프로젝트별로 일일 공수를 관리하기 위한 project_daily_works 테이블 추가

**상세 설명:**
- 변경 이유: 기존 daily_works는 전체 공수만 관리하여 프로젝트별 공수 추적 불가
- 영향받는 테이블: 없음 (신규 테이블)
- 새로 추가된 테이블: project_daily_works
- 삭제된 컬럼/테이블: 없음

#### 마이그레이션 정보
- **파일명:** `009_add_project_daily_works_table.sql`
- **실행 순서:** 008 이후
- **롤백 가능 여부:** Yes
- **데이터 손실 위험:** None

#### SQL 스크립트
```sql
CREATE TABLE project_daily_works (
    id SERIAL PRIMARY KEY,
    date DATE NOT NULL,
    project_id BIGINT NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
    hours FLOAT NOT NULL,
    created_by_id INTEGER NOT NULL REFERENCES users(id),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_project_daily_works_date ON project_daily_works(date);
CREATE INDEX idx_project_daily_works_project_id ON project_daily_works(project_id);
CREATE INDEX idx_project_daily_works_date_project ON project_daily_works(date, project_id);
```

#### 테스트 체크리스트
- [x] 로컬 환경에서 테스트 완료
- [x] 기존 데이터 호환성 확인
- [ ] 애플리케이션 코드 업데이트 완료
- [ ] API 테스트 완료
- [x] 성능 영향 확인

#### 영향도 분석
**애플리케이션 영향:**
- 백엔드 API: 영향 있음 (새 API 엔드포인트 필요)
- 프론트엔드: 영향 있음 (프로젝트별 공수 입력 UI 필요)
- 기존 데이터: 영향 없음

**호환성:**
- 이전 버전과의 호환성: 유지
- 필요한 코드 변경사항: 있음

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [008] - 프로젝트 ID를 BIGINT로 변경 (2025-10-25)

#### 변경 유형
- [x] 기존 테이블 수정
- [x] 컬럼 추가/삭제/수정

#### 변경 내용
**요약:** 데이터 타입 일관성을 위해 project_id를 BIGINT로 변경

**상세 설명:**
- 변경 이유: 향후 대용량 데이터 처리 및 타입 일관성 확보
- 영향받는 테이블: projects, issues
- 수정된 컬럼: projects.id, issues.project_id
- 삭제된 컬럼/테이블: 없음

#### 마이그레이션 정보
- **파일명:** `008_fix_project_id_bigint.sql`
- **실행 순서:** 007 이후
- **롤백 가능 여부:** Yes (데이터 범위 내에서)
- **데이터 손실 위험:** None

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [007] - 부적합 사항에 프로젝트 ID 추가 (2025-10-25)

#### 변경 유형
- [x] 기존 테이블 수정
- [x] 컬럼 추가/삭제/수정
- [x] 제약조건 추가/삭제

#### 변경 내용
**요약:** issues 테이블에 project_id 컬럼 추가하여 프로젝트별 부적합 사항 관리

**상세 설명:**
- 변경 이유: 부적합 사항을 프로젝트별로 분류하여 관리 필요
- 영향받는 테이블: issues
- 새로 추가된 컬럼: issues.project_id
- 삭제된 컬럼/테이블: 없음

#### 마이그레이션 정보
- **파일명:** `007_add_project_id_to_issues.sql`
- **실행 순서:** 006 이후
- **롤백 가능 여부:** Yes
- **데이터 손실 위험:** None

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

### [006] - 프로젝트 테이블 추가 (2025-10-25)

#### 변경 유형
- [x] 새 테이블 추가
- [x] 인덱스 추가/삭제

#### 변경 내용
**요약:** 프로젝트 관리를 위한 projects 테이블 추가

**상세 설명:**
- 변경 이유: 여러 프로젝트를 관리하고 부적합 사항을 프로젝트별로 분류 필요
- 영향받는 테이블: 없음 (신규 테이블)
- 새로 추가된 테이블: projects
- 삭제된 컬럼/테이블: 없음

#### 마이그레이션 정보
- **파일명:** `006_add_projects_table.sql`
- **실행 순서:** 005 이후
- **롤백 가능 여부:** Yes
- **데이터 손실 위험:** None

#### 담당자
- **개발자:** AI Assistant
- **검토자:** -
- **승인자:** -
- **적용일:** 2025-10-25

---

## 다음 변경 예정 사항

### 우선순위 높음
- [ ] 부적합 사항 우선순위 필드 추가
- [ ] 프로젝트 상태 관리 (진행중, 완료, 보류)
- [ ] 알림 시스템 테이블 설계

### 우선순위 중간
- [ ] 파일 첨부 기능 확장
- [ ] 감사 로그 테이블 추가
- [ ] 사용자 권한 세분화

### 우선순위 낮음
- [ ] 데이터 아카이빙 전략
- [ ] 성능 최적화를 위한 파티셔닝
- [ ] 전문 검색 기능

---

## 변경 승인 프로세스

1. **계획 단계**
   - 요구사항 분석
   - 영향도 평가
   - 마이그레이션 스크립트 작성

2. **검토 단계**
   - 코드 리뷰
   - 테스트 계획 수립
   - 롤백 계획 수립

3. **테스트 단계**
   - 로컬 환경 테스트
   - 스테이징 환경 테스트
   - 성능 테스트

4. **배포 단계**
   - 백업 수행
   - 마이그레이션 실행
   - 검증 테스트
   - 모니터링

---

**문서 관리자:** 개발팀  
**최종 업데이트:** 2025-10-25  

> 모든 데이터베이스 변경사항은 이 문서에 기록되어야 하며, 변경 전 반드시 검토 과정을 거쳐야 합니다.